Managing ID token expiration

12816 views
Skip to first unread message

Martin Stadler

unread,
Sep 22, 2016, 1:16:39 PM9/22/16
to Firebase Google Group
Hi,

I'm authenticating my web client with firebase.auth() and then getting an ID token with user.getToken() to authenticate requests to a custom backend API.

What's the recommended way to manage this token's life time? What is the expiration time? Can I set a custom expiration?

Is it true, that firebase.auth() is managing an unlimited session for the user or will it logout or the session expire at some point?

In this context: when will firebase.auth().onAuthStateChanged be triggered?

Thanks,
Martin

Jacob Wenger

unread,
Sep 26, 2016, 10:02:38 AM9/26/16
to fireba...@googlegroups.com
Hey Martin,

Lots of questions here, but let's see if I can answer all of them for you.

ID tokens expire one hour after creation. You cannot change this expiration time. Under the hood, the client SDKs refresh the ID token using a long-lived token we call a refresh token. The refresh token is used to generate a new ID token every hour which allows the client SDKs to continue to work seamlessly. The refresh token allows the client to stay logged in indefinitely until you call signOut() or a session invalidation event like a change in password or email happens from another client device. You don't need to do anything to manage the ID token's lifecycle. The client SDKs do all of that for you. Whenever you need to use the ID token from your custom backend, send the current token along with the request from the client. I would not suggest persisting ID tokens on your server since their lifetime is so short.

Lastly, onAuthStateChanged() is called once upon page load and then every time an auth state event occurs. Auth state events include a sign in or a sign out. Technically, the client SDKs will also fire onAuthStateChanged() every time a new ID token is minted, but this may be changing in an upcoming release so I wouldn't rely too much on this behavior. Instead, I'd just call currentUser.getToken() whenever you need the latest fresh ID token. Every time the listener onAuthStateChanged() is called, it is passed the current Firebase user. If this is null, there is no logged-in user. Otherwise, there is a logged-in user.

Hope that helps,
Jacob

--
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-talk+unsubscribe@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/9dd593eb-1f8a-470b-95c0-0f40cf3562db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ian

unread,
Sep 28, 2016, 7:58:38 PM9/28/16
to Firebase Google Group
Hi Jacob,
 
ID tokens expire one hour after creation. You cannot change this expiration time. Under the hood, the client SDKs refresh the ID token using a long-lived token we call a refresh token. The refresh token is used to generate a new ID token every hour which allows the client SDKs to continue to work seamlessly. The refresh token allows the client to stay logged in indefinitely until you call signOut() or a session invalidation event like a change in password or email happens from another client device. You don't need to do anything to manage the ID token's lifecycle. The client SDKs do all of that for you. Whenever you need to use the ID token from your custom backend, send the current token along with the request from the client. I would not suggest persisting ID tokens on your server since their lifetime is so short.

Thank you very much for your explanation! We use JWT Authorization headers to authenticate requests against a server. However, the server itself can't validate Firebase Auth tokens, so a backend is called to do this. Because the backend should not be called on every single request to the server, we wanted to cache the validation response for the lifetime of the JWT.

How do you think about that? And does the client SDK refresh the token some time before expiration? The reason I'm asking is that there might be a request coming from the client at 59 minutes, 59 seconds and 999 milliseconds sending a token that is going to become invalid within a millisecond. This could lead to an error on the server-side, but I assume that the client SDK refreshes tokens on a rolling basis with some overlapping to prevent something like this from happening, just like Google Authenticator codes?

Thanks for your help,
Ian

Jacob Wenger

unread,
Sep 29, 2016, 12:52:44 PM9/29/16
to fireba...@googlegroups.com
Hey Ian,

The server itself can't validate Firebase Auth tokens

Why is that? Is it because you don't control the server? You can in fact validate Firebase ID tokens as described here. You can either use the Firebase SDK itself if the server runs Node.js or Java or use a third-party JWT library if your server is in another language.

Does the client SDK refresh the [ID] token some time before expiration?

Unfortunately, this is not the case :( We will only refresh the ID token after a call using the previous token fails. We consider this a bug though and are actively working to fix this in an upcoming release. In the future, we will optimistically refresh the ID token as you are suggesting. I don't have a release date for when that will happen though.

If you have follow-up questions, it would help me out a lot if you can take a step back and tell me what your use case is and why you need to have this intermediate backend proxy in the first place. In 99% of cases, something like that is not required and this may be a bit of an XY problem. If you can give me some context, that would be great and maybe I can help lead you to a simpler solution.

Cheers,
Jacob

--
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-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.

Ian

unread,
Sep 29, 2016, 1:54:12 PM9/29/16
to Firebase Google Group
Hi Jacob,

Thank you very much for your help!
 
The server itself can't validate Firebase Auth tokens

Why is that? Is it because you don't control the server? You can in fact validate Firebase ID tokens as described here. You can either use the Firebase SDK itself if the server runs Node.js or Java or use a third-party JWT library if your server is in another language.

We use Varnish and would be able to verify a HS256 JWT using Varnish's VCL but unfortunately Firebase uses RS256 and I think, there is no way to switch to HS. That's why we connect to the backend to validate an unknown JWT and want Varnish to cache the result until the token expires for subsequent requests.

Does the client SDK refresh the [ID] token some time before expiration?

Unfortunately, this is not the case :( We will only refresh the ID token after a call using the previous token fails. We consider this a bug though and are actively working to fix this in an upcoming release. In the future, we will optimistically refresh the ID token as you are suggesting.

+1 :-)

Best regards,
Ian

Jacob Wenger

unread,
Sep 29, 2016, 1:58:19 PM9/29/16
to fireba...@googlegroups.com
Thanks for the info regarding Varnish, Ian. That's good to know your use case. Keep an eye out for a future release of our SDKs which improve the ID token refresh process.

Cheers,
Jacob

--
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-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages