Firebase session expiration

Question

It looks like Firebase, when they moved from the v2 to v3.x SDKs (and now into v4), decided to remove the option for automatic session expiration in favor of the always-authenticated model.

• Firebase 3.x - Token / Session Expiration
• https://groups.google.com/forum/#!topic/firebase-talk/uYMlQny1Jb4

This is a nice feature to offer, but from a cybersecurity perspective, I see some problems as this is the only option for the Firebase SDKs with Firebase-generated tokens such as email and password authentication (some of which are explained well in the linked google group discussion).

The commonly-provided suggestion to call user.signOut() on page exit has some holes. Namely, if the client crashes, then this code is never executed and therefore the strategy falls apart. The "sign out on page load" suggestion also has holes in it:

1. Forces all users to log in every time the page loads/reloads (not the goal)
2. As Firebase pushes most everything to the client, there is nothing stopping someone for creating a script that attempts to access a targeted Firebase without having the user.signOut()

I'm looking for a strategy that does a better job, from a cybersecurity perspective, that allows a user to opt in to the "always-authenticated" strategy if he/she so chooses, rather than it being the default (i.e. with a "Remember Me" button).

One strategy I came up with is as follows:

1. User signs in
2. Get the generated JWT for that session and write it to Firebase
3. If the user didn't select "remember me" on sign in, set up an onDisconnect handler that clears the token from the list of that users tokens
4. In Firebase security rules, ensure that the JWT for the user making the request is in the list of tokens for that user

This feels more secure because the onDisconnect method will still execute even if the browser crashes. But, the JWT is not available as a Firebase rules variable (only the contents of the token)!

In light of these issues/flawed approaches, how can I invalidate a session after the browser closes/crashes (or even after a pre-determined period of time) with a Firebase-generated token?

Solution

here is a suggestion: The ID token has an auth_time field. This is the time the user authenticated, you can force whatever session length you want. You can enforce that if you validate the token on your server or via database rules using https://firebase.google.com/docs/reference/security/database/#now and auth.token.auth_time. Check https://firebase.google.com/docs/reference/security/database/#authtoken.

You would require the user reauthenticate to access the data. Reauthentication will update the auth_time in the token.

This is a better approach since keeping track of all ID tokens will not scale well and ID tokens expire after an hour and new ones will be refreshed after the user returns to the app but will maintain the same auth_time.

Not sure if this will alleviate your concerns but Firebase is looking into the following features:

1. The ability to specify persistence for web authentication. This is similar to how sessionOnly auth worked in Firebase 3.x. This will make "Remember Me" functionality easy to implement.
2. The ability to revoke sessions.

Comments

[MandM]

Hey @bojeil, thanks for the suggestion. I think there's some edge cases here when it comes to multi-tenant scenarios (a user may be unknowingly "extending" the sessions of other users logged into the same account by updating the auth_time), but it's a decent solution for the meantime. Any timelines on those other features? :)

[bojeil]

What do you mean "a user may be unknowingly "extending" the sessions of other users logged into the same account by updating the auth_time". auth_time is only updated on reauthentication or sign-in. There are no solid timelines for these features at the moment.

[MandM]

I wrote an entire explanation about User A and User B signing in from different machines, and one basically updating the auth_time of the other, but then realized I was being silly because that auth_time is not shared as it is a part of their individual JWTs. Thanks! Another feature to consider would be to allow custom JWT claim definition via Email & Password auth rather than requiring a separate server.

[bojeil]

Custom JWT claims have to be provided via a trusted authority (admin SDK on a developer's server, Firebase Functions, etc) and not the client. Custom JWT claims are used to set levels of access (if a user is an admin, paid subscriber, etc). Firebase is also looking into that as it is a very important functionality.