Are ID tokens permanent/unrevocable?

181 views
Skip to first unread message

twinkle...@gmail.com

unread,
Jul 19, 2017, 2:36:50 PM7/19/17
to Firebase Google Group
The documentation certainly explains how to verify an ID token on my server: https://firebase.google.com/docs/auth/admin/verify-id-tokens

…but it doesn't mention how long ID tokens last or, really, if they are revocable. Maybe they thought it was obvious, but usually tokens can be invalidated (auth credential change, user disabled…)

Are there any such cases? And what is correct behavior of an app backend service that works with the ID token. Should it 'verify' on every request from app? Or just once as the documentation implies?

Thanks,
Julian

Hiranya Jayathilaka

unread,
Jul 19, 2017, 2:48:06 PM7/19/17
to fireba...@googlegroups.com
Hi Julian,

ID tokens are short-lived. They expire after 1 hour.

Unless you do some kind of session management in the backend server, you will have to perform ID token verification for each individual user/app request.

Thanks,
Hiranya

--
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/c9593746-ceb6-42e1-b5f9-2c4627e23c86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Hiranya Jayathilaka | Software Engineer | h...@google.com | 650-203-0128

twinkle...@gmail.com

unread,
Jul 19, 2017, 4:36:26 PM7/19/17
to Firebase Google Group
This still requires the app to provide the new ID tokens on subsequent requests.

I am guessing that the suggested way to do this while the app is open is 'Auth listener'. And "The current user's access token" (on https://firebase.google.com/docs/auth/users#auth_tokens) means the ID token?

And the app will still need to do a getToken task at launch (even if currentUser exists) and pass it to my backend?

Last, by any chance is there a way for the server (or app even) to know the expiration time?

Thanks,
Julian


On Wednesday, July 19, 2017 at 1:48:06 PM UTC-5, Hiranya Jayathilaka wrote:
Hi Julian,

ID tokens are short-lived. They expire after 1 hour.

Unless you do some kind of session management in the backend server, you will have to perform ID token verification for each individual user/app request.

Thanks,
Hiranya
On Wed, Jul 19, 2017 at 11:06 AM, <twinkle...@gmail.com> wrote:
The documentation certainly explains how to verify an ID token on my server: https://firebase.google.com/docs/auth/admin/verify-id-tokens

…but it doesn't mention how long ID tokens last or, really, if they are revocable. Maybe they thought it was obvious, but usually tokens can be invalidated (auth credential change, user disabled…)

Are there any such cases? And what is correct behavior of an app backend service that works with the ID token. Should it 'verify' on every request from app? Or just once as the documentation implies?

Thanks,
Julian

--
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/c9593746-ceb6-42e1-b5f9-2c4627e23c86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hiranya Jayathilaka

unread,
Jul 19, 2017, 5:04:09 PM7/19/17
to fireba...@googlegroups.com
On Wed, Jul 19, 2017 at 12:08 PM, <twinkle...@gmail.com> wrote:
This still requires the app to provide the new ID tokens on subsequent requests.

I am guessing that the suggested way to do this while the app is open is 'Auth listener'. And "The current user's access token" (on https://firebase.google.com/docs/auth/users#auth_tokens) means the ID token?

The AuthStateListener will notify your app every time the underlying ID token is refreshed. You can call getCurrentUser().getIdToken() to retrieve the ID token:



And the app will still need to do a getToken task at launch (even if currentUser exists) and pass it to my backend?

If your app needs to call backend servers at launch and invoke some function that requires authentication, you need to do this.
 

Last, by any chance is there a way for the server (or app even) to know the expiration time?

This is available on the decoded ID token returned by verifyIdToken() call:

 

Thanks,
Julian

On Wednesday, July 19, 2017 at 1:48:06 PM UTC-5, Hiranya Jayathilaka wrote:
Hi Julian,

ID tokens are short-lived. They expire after 1 hour.

Unless you do some kind of session management in the backend server, you will have to perform ID token verification for each individual user/app request.

Thanks,
Hiranya

On Wed, Jul 19, 2017 at 11:06 AM, <twinkle...@gmail.com> wrote:
The documentation certainly explains how to verify an ID token on my server: https://firebase.google.com/docs/auth/admin/verify-id-tokens

…but it doesn't mention how long ID tokens last or, really, if they are revocable. Maybe they thought it was obvious, but usually tokens can be invalidated (auth credential change, user disabled…)

Are there any such cases? And what is correct behavior of an app backend service that works with the ID token. Should it 'verify' on every request from app? Or just once as the documentation implies?

Thanks,
Julian

--
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/c9593746-ceb6-42e1-b5f9-2c4627e23c86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--

Hiranya Jayathilaka | Software Engineer | h...@google.com | 650-203-0128

--
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.

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

twinkle...@gmail.com

unread,
Jul 19, 2017, 7:48:25 PM7/19/17
to Firebase Google Group
One last question. I think I have come to an understanding about the lifecycle of the tokens. I just had one thought about *why*. The purpose of the ID token is to allow a server to securely get the uid. But there are no other uses for this ID token, it seems - everything is by uid, which of course can't change during a login session.

I assume that there is some mailicious behavior detection in Firebase, so that a user may suddenly lose access (similar to being disabled?). In short, if my server doesn't maintain ID token and re-verify during one login session, then "all that happens" is I run the risk of letting a blocked Firebase user continue to use my app, right? I have my own field for account status for my app anyway, and I do not plan to use any other Firebase user APIs.

Hiranya Jayathilaka

unread,
Jul 19, 2017, 8:19:49 PM7/19/17
to fireba...@googlegroups.com
If you're doing session management in your server, then you don't necessarily have to do ID token verification on each request. You can perform verification on the first request, and proceed to establish a session. This is probably the most efficient way to implement the backend server too, since ID token verification can be fairly expensive. The worst that can happen in this case is, as you mentioned, the user will continue to have access to the server operations as long as the session is alive. 

You however, need to ensure that ID tokens do not get leaked/exposed. That would allow an attacker to establish a session while the token is valid, and then continue to access the server indefinitely. Incidentally, I believe this is exactly why ID tokens are short-lived. That makes sure that even if an ID token accidentally gets leaked, an attacker has a fairly small window to do something with it. 



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.

For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages