"sessionOnly" auth with Firebase 3?

[Ben Mueller]

Hi,

In Firebase 2.x, it was possible to limit an authentication session to the browser session, by doing something like this:

  datasource.authWithOAuthRedirect("google",
    (error, authData) => {
      if(error) {
          reject({message: error.message, obj:error})
      } else {
          resolve(authData);
      }
    },
    { remember: "sessionOnly", scope: "email" }
  ) });

...the key part being remember: "sessionOnly".

Does Firebase 3.x support the same? The auth methods have changed, and at least in the JS documentation (which I know are not up to date yet), there is no mention of being able to control session length.

Help?

[Michael Bleigh]

Session durations are infinite now by design. Only in certain extreme cases (password change, delete, etc) do we require reauthentication.

Session-only authentication is not supported in the Firebase 3.0 SDK, but the Auth team is taking it as a suggestion for future consideration.

Cheers,

Michael

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/e7592a4a-40e4-45ad-9378-03ce1d2cc21a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Mueller]

Hmm...this feels like a bummer. I'm just trying to think through the implications. A few questions/comments:

* If a person uses a Firebase-backed web app on a public machine (e.g. library), then closes their browser, and the next person finds a link to that app in the browser history, is that second person going to be authenticated in that app? Because that seems bad.

* Does this mean that Firebase sessions never time out? So if I log into my Firebase-backed web app, then leave on vacation for two weeks without shutting the browser down, and then return, I'm still authenticated?

* I'm not 100% sure how authenticating against a third-party like Google/Facebook/etc is supposed to work. Can one set a timeout for their Google authentication? If so, then does that means it's possible to log into a Firebase app via Google, then have your Google auth timeout, but yet still be authenticated with the Firebase app? If so, that seems bad.

* Performing JS operations on window close is historically pretty darned bad. Having said that, is there a reliable way of killing a Firebase auth session on window close? 

I dunno--I get that authentication sucks for everybody all the time, and so not forcing people to authenticate all the time is great, but it does seem like there are legit cases where people would want an app to de-auth after some amount of inactivity.

[Alfonso Gomez Jordana Manas]

Hi Ben, thank you for your comments, we are taking all of this as valuable feedback.

Responses to your questions inline:

On Tuesday, May 24, 2016 at 7:20:02 AM UTC-7, Ben Mueller wrote:

Hmm...this feels like a bummer. I'm just trying to think through the implications. A few questions/comments:

* If a person uses a Firebase-backed web app on a public machine (e.g. library), then closes their browser, and the next person finds a link to that app in the browser history, is that second person going to be authenticated in that app? Because that seems bad.

This is the current default behavior, yes.

As a workaround, you can manually call signOut() on the user on page load or before the window closes, if you detect a user is signed in and you don't want them to be.

 

* Does this mean that Firebase sessions never time out? So if I log into my Firebase-backed web app, then leave on vacation for two weeks without shutting the browser down, and then return, I'm still authenticated?

This is correct. They time out only if a big account change happens (e.g. the account is deleted, the account password or email are changed, etc.)

 

* I'm not 100% sure how authenticating against a third-party like Google/Facebook/etc is supposed to work. Can one set a timeout for their Google authentication? If so, then does that means it's possible to log into a Firebase app via Google, then have your Google auth timeout, but yet still be authenticated with the Firebase app? If so, that seems bad.

This is how it happens, by design. Note that, as mentioned above:

1) You can manually use auth().signOut() to sign your users out when you desire.

2) Sessions do expire when we detect big account changes.  

 

* Performing JS operations on window close is historically pretty darned bad. Having said that, is there a reliable way of killing a Firebase auth session on window close? 

I would recommend doing it on window close but this does not cover all cases, e.g. if the browser is killed. So just in case it, you would have to include a check on window load (if auth().currentUser != null) and sign out there too.

[Ben Mueller]

Thanks very much for your reply. Might I politely suggest you bring back session timeouts?  (-;

I will try to handle this as you suggest (e.g. on load, log out the user, and/or try to do something on window.close, but neither of those cases are bulletproof).

It kind of sounds like you're gunning for the Netflix "always authenticated" model, which certainly works for that use-case (and many others, including lots of native apps). Our use-case is somewhat different. We are building, without getting into too much detail, something akin to an online classroom, and when the "class" is over, we don't think it makes good sense to allow the student/teacher sessions to persist. Given that users rarely close their browser windows (especially on mobile), to date we have relied on a 2-hour session timeout. And now that I think about it, window.close and/or log out user on initial page load won't work for mobile at all, since those pages are just put into hibernation, rather than being closed.

Anyway, thanks for being so responsive!

Ben

[Kato Richardson]

Hi Ben,

Great suggestions. One more temporary workaround occurred to me. While you can't rely on this for fully securing your app, you could solve the library scenario (i.e. a non-hacker pulling up an abandoned URL) by assuming the user is signed out on page load, or by specifically calling signOut() on page load, rather than trying to load previous auth credentials, effectively forcing session level auth.

Not perfect, but at least a step in the right direction.

☼, Kato

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/0f61f7c0-6718-47dc-822d-82ab44ccea9d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Jin Liu]

Hi Ben,

In case you have your own server to validate the Firebase auth token, here is another way to enforce the 2-hour session timeout from your server. Inside the Firebase auth token, there is a field named 'auth_time'. It remains to be the timestamp that the user initially signed into your app using password/Google/etc, no matter how long the session duration is.

Jin

[Ben Mueller]

Thanks for the tip! Unfortunately, Firebase is our only backend at this point. We may roll our own backend server at some point, whereupon we could handle auth/session management by means other than Firebase. One of the beauties of Firebase, though, is that we don’t need anything else, which keeps things nice and simple.

Ben

You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/uYMlQny1Jb4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.

To post to this group, send email to fireba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/db5a077b-ee18-40a2-8d26-bad4c38f28ca%40googlegroups.com.

[Ben Mueller]

Coming back to this...

So wouldn't a page refresh be the same as a load? Obviously that's no good, since you wouldn't want a user to get logged out every time they refresh their browser.

[Anand Patel]

If you don't want to use a backend to authenticate the token, you could do the following. For us only certain calls talk to our backend so we can't also check the token so have implemented the following for the frontend to check session:

1. When use logs in, create a session object in firebase, with based details about session, e.g. device, time created, and set expiry. Watch the object from front end. 

2. Then on every route change (we using angularjs so we can check this before page loads), we check if session has expired, if not we update the session expiry by X hours (use is active) or log out if expired and redirect.

Hope that helps, no backend required. 

[Vincent Bergeron]

Hi folks!

Here`s what I did to have the same behavior of sessionOnly and be compatible with the old Firebase SDK 2. I'm using Angular 1.

var fbApp = null;
function Firebase(url) {
   var rootRef = fbApp.database().ref();

   url = url.replace(/^https:\/\/.*.firebaseio\.com/, "");
   if (url == "") {
      url = "/";
   }
   return rootRef.child(url);
}

angularModule.config(function($sessionStorageProvider) {

    var firebaseAppName = $sessionStorageProvider.get('firebaseAppName') || "fbApp_"+moment().format();
    $sessionStorageProvider.set('firebaseAppName', firebaseAppName);

    fbApp = firebase.initializeApp(firebaseConfig, firebaseAppName);
})

So the $sessionStorage will have the same firebaseAppName as long as the TAB is opened. A new tab, a new name, a new firebase app, a new auth.

The only caveat is Firebase will keep it`s list in localStorage. So it will grow over time. What I think I'll do is keep a list of firebaseAppName in the local storage and call signOut() on each app once in a while...

What do you think if this?

VB

[Bassam]

Firebase Auth JS SDK now supports sessionOnly persistence. For more on this, check https://firebase.google.com/support/release-notes/js#4.2.0 and https://firebase.google.com/docs/auth/web/auth-state-persistence

Best regards,

Bassam