The Firebase authentication token expires in one hour. When the user logs out, and then logs back in, if the token of the past session does not have an expired lifetime, it is still read as valid. Is there a way to disable the token of the last user session if it still has a lifetime?
Related
I am new to firebase.
I don't understand how I can keep the users of my firebase app logged in when the max expiration time of an auth token in 1 hour.
I could use a function that uses the refresh token every hour but what do I do if the users phone isn't charged?
Thank you very much for any help.
A Firebase user's access token (or ID token) has a lifetime of an hour. After signing in the user, Firebase issues a refresh token that is used to get new access tokens if that refresh token is still valid and hasn't been revoked. If you are using the Firebase Client SDKs, they will handle getting new ID tokens as needed for you. Refer to the ID tokens documentation for more information.
An ID token essentially states "within the last hour, I have confirmed that I am this user".
If you are making use of Custom Authentication tokens from an Admin SDK, the token you give out to the caller also expires in an hour, but should be exchanged for a refresh token before it expires. Like described above, this new refresh token is used to request new ID tokens as they expire.
Firebase uses multiple token types to manage the authentication state of the user. The shortest lived of these (known as the ID token) expires an hour after it was created, but all Firebase SDKs actually automatically refresh that ID token before it expires.
This is handled for you behind the scenes, so in practice you shouldn't have to worry about token expiration - and your code can just get the currently signed in user everywhere it needs.
I understand that the ID token are JWT with an expiry. However, I am curious if there is a way to set some sort of expiry on the refresh token given by Firebase sign in that allows us to call Firebase to get a fresh ID token - AFAIK these never expire.
Refresh tokens don't expire after a certain time interval. The Firebase documentation on managing user sessions says:
Refresh tokens expire only when one of the following occurs:
The user is deleted
The user is disabled
A major account change is detected for the user. This includes events like password or email address updates)
But you can revoke the refresh token (since it's really just an OAuth2 token). See the documentation on revoking refresh tokens for more on that.
I am able to allow users to log in to Firebase using email and password. I followed these instructions: https://firebase.google.com/docs/reference/rest/auth/#section-sign-in-email-password
However, after 1 hr it seems the auth expires and I can't use my app anymore. Does anybody know how I can extend that hour? I have read MULTIPLE posts with very similar questions, but I can't find a clear answer. IT seems some people think there is a way to obtain a reauth token or something like that, but still no clear answer.
Manage User Sessions
Firebase Authentication sessions are long lived. Every time a user signs in, the user credentials are sent to the Firebase Authentication backend and exchanged for a Firebase ID token (a JWT) and refresh token. Firebase ID tokens are short lived and last for an hour; the refresh token can be used to retrieve new ID tokens. Refresh tokens expire only when one of the following occurs:
The user is deleted
The user is disabled
A major account change is detected for the user. This includes events like password or email address updates.
Manage Tokens on Web Client
The website client code can call User.getIdToken(forceRefresh?: boolean):
Returns the current token if it has not expired. Otherwise, this will refresh the token and return a new one.
This would need to be called each time a token is sent to the server.
Alternatively, user sessions may be managed via session cookies.
Manage Session Cookies
Firebase Auth provides server-side session cookie management for traditional websites that rely on session cookies. This solution has several advantages over client-side short-lived ID tokens, which may require a redirect mechanism each time to update the session cookie on expiration:
Improved security via JWT-based session tokens that can only be generated using authorized service accounts.
Stateless session cookies that come with all the benefit of using JWTs for authentication. The session cookie has the same claims (including custom claims) as the ID token, making the same permissions checks enforceable on the session cookies.
Ability to create session cookies with custom expiration times ranging from 5 minutes to 2 weeks.
Flexibility to enforce cookie policies based on application requirements: domain, path, secure, httpOnly, etc.
Ability to revoke session cookies when token theft is suspected using the existing refresh token revocation API.
Ability to detect session revocation on major account changes.
Maybe a simple question.
Lets say that the user receives the bearer token and has an expire time of 1 day.
the user makes calls to the web api and then stops making calls say after 6 hours.
Then if the user makes a call to the web api does that auto refresh the token and then the user has another 24 hours to use the token or will it definatly expire based on the first get of the token.
thanks
Once issued, the token cannot be changed and will be valid until it expires. It doesn't matter how or when the token was used or even if other tokens were requested in the meantime.
Since the token cannot be changed, the expiration of the token cannot be extended. The token can however be revoked before it expires, based on other factors, if the server is configured to do so.
It may not be possible to extend the token itself, but it is possible to request a new token without having to send the credentials.
You can configure the server to add a refresh token to the token. Please note that this is not available for all grant_types. In case of a refresh token the normal token has an extra parameter 'refresh_token' that contains an additional token with its own expiration time. This token can be used once the normal token is expired. In that case a new token can be requested with this refresh token, without having to send the credentials.
I'm trying to make the presence & token expiry a little more resilient in my app.
My presence table creates a record on login with the login timestamp and then when the user closes the session the server records to logout timestamp via the onDisconnect() function.
However, when the auth token expires it does not automatically disconnect the session and as such my presence indicator still shows the user is online. Furthermore, if a user then reconnects on the same browser it looks as if the user is logged in twice as it still has not recorded the onDisconnect from the first session.
Should the expiry of the auth token automatically disconnect the session or am I meant to watch for the disconnect and disconnect the session myself?
There is different between authentication and connection. You can listen at /.info/authenticated for authenticate-state (Firebase docs).
The problem should be when your onDisconnect operation needs auth rights - because of security rules.
All firebase auth tokens have an expiry time, this is returned to you in the authlistener. You can disconnect after this expiry time is passed. I am unsure what language/API you are using towards firebase, but the APIs are mostly the same between android/ios/web.