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.
Related
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 not sure what a proper FCM token handling mechanism would be so I’m writing our process down here just to get some validation or suggestions for improvements:
Fetch FCM token on client Login (Flutter)
Save FCM token on our Database (Using our REST API)
Delete FCM token on Logout (Using our REST API)
Q1: Should we be getting the FCM token more often than just on login? AFAIK, FCM token only changes on app re-installs, clearing cache, etc. Does this also include app-updates from the PlayStore? In that case, should we save the FCM token on every app launch since the user will remain logged in after an app update and hence we wouldn't trigger the save FCM call.
Q2: Did I mention the right way to handle deleting FCM tokens from our DB? We don’t want the user to keep getting notifications once they have logged out.
Q3: An add-on idea is to send the device_id to the server along with the fcm_token so that server deletes all previously saved FCM tokens for that device_id. This is useful to not have useless tokens on the DB from cases where the user uninstalls the app without logging out (which means that the DELETE fcm_token call never went through.)
The FCM token is refreshed under conditions that you don't control, and those conditions have even changed over time. To handle token updates properly, you'll need to implement both initially getting the token and then monitoring for token updates.
Note that FCM tokens are not associated with a user. It is fine if you want to associate them with a user, but it's up to your application code in that case to maintain the association. So that for example includes deleting the token from your database when the user signs out, as you're doing in step 3. 👍
For keeping your token registry clean, you can indeed do this proactively as you intend, or reactively as shown here: https://github.com/firebase/functions-samples/blob/master/fcm-notifications/functions/index.js#L76-L88
Hi Rohan fundamentaly you should use below logic to save tokens on server.
Step1:
as soon as you get token in callback whether new or same try to save it localstorage.
Step2:
Call your REST API to save it to your server. it is upto you if you want to send unique user identifier along with the token.
Step3:
It is obvious you will recieve token callback a lot of time so you can check whether you have similar token in localstorage, it means you have the token on the server so no point calling REST API.
Step 4: Now your app can send events back to server and based on it trigger Push notifications to the users.
Step 5: You can Add/update user token based on uniqye user identifier. In some cases a user can be guest user, so your app should generate guest userId and link it with token.
Stay safe.
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.
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?
This is a general question regarding web session management.
What is the best practice approach to managing session timeout?
Assume a system where a user logs in, a session is created on the server, and a token identifier is sent back to the client (via httpOnly cookie).
If the user attempts some access-based check where the session is validated, presumably it makes sense to update an expiry time on the session in the DB. Does this also mean that when this happens, we should update the expiry time on the session token cookie to match?
This seems like the most obvious solution to me, but constantly rewriting the cookie seems like a lot of overhead.
Any insight into best-practice approaches is greatly appreciated. Thanks!
How to manage session timeout to keep user logged-in, prevent he/she from accidental logout?
To keep user logged-in, it is not necessary to constantly rewrite the cookie. All you need to do is making the session token cookie's expires as Session, then as long as browser is open (client keeps using your site), the session token cookie is valid. Server does not need to know the session expires time (as there is no pre-defined session expires time any more), not mention store it in DB. After user close the browser, the session token cookie is cleared, and session is terminated (invalidated).
Normally, there will be a "session timeout" setting in server, such as session-timeout in Struts2, which kills the session if client doesn’t make any request after some time.
How to make session "validate" even if user closes the browser? That is, how to implement the "remember me for 1 week" feature?
To implement this feature, a new token cookie is used (e.g. RememberMeToken). When user login successfully (possibly enable the "Remember me" checkbox on UI), server will generate a unique random token and store it in DB (together with its expires time for security reason), make it belong to user account. This RememberMeToken cookie's expires time is pretty long (1 week for example), and will be sent back to browser together with login response.
When user close the browser and re-visit the site later (or the user is inactive for long time and the session is killed in server side), server checks session token cookie and find it's missing/invalid. At this point, RememberMeToken will be checked and compared with token stored in DB, if there is a match, server will make auto-login operation for corresponding user, and return generated session token cookie to browser. This all happens in backend, client user won't feel anything.
After 1 week since user enable the "Remember me" checkbox on UI and login, the RememberMeToken cookie is expired, and user need to login again if he/she opens browser and visit the site.