Firebase Official docs says that Firebase Token ID of a user expires in 1 hour . to generate a new token refresh token id is to be passed to an end point where in response the client receives new token id .
So question is that to keep a persistent Loged in behaviour in my react native app while user is not using app in foreground for hours would i have to start a background service that refreshes Firebase Token ID after every hour? or is their a better and easy way to keep firebase token id for users refreshed and keep user loged in.
Firebase Auth State Persistence (recommended)
The Firebase web API provides the following options for Authentication State Persistence:
local: Indicates that the state will be persisted even when the browser window is closed or the activity is destroyed in React Native. An explicit sign out is needed to clear that state. Note that Firebase Auth web sessions are single host origin and will be persisted for a single domain only.
session: Indicates that the state will only persist in the current session or tab, and will be cleared when the tab or window in which the user authenticated is closed. Applies only to web apps.
none: Indicates that the state will only be stored in memory and will be cleared when the window or activity is refreshed.
Using the Firebase state persistence API directly is by far the most straight forward solution.
However, if you are set on implementing state persistence from scratch using the Firebase Admin SDK, then you could do the following.
Custom State Persistence (not recommended)
User signs in.
The Firebase user ID and a secret token generated by the server are saved in storage, for example, React Native AsyncStorage. The secret token is also stored in a database.
While the app is running, refresh tokens are periodically retrieved to keep the session live.
User closes the app.
User opens the app.
App checks storage for the Firebase user ID and the secret token. If found, these are sent to the server to confirm if the secret code matches the code stored in the database.
If the secret code matches, the server then generates a custom auth token based on the Firebase user ID and sends back to the React Native app.
The React Native app automatically signs in the user with the custom auth token.
Use react-native-firebase lib.
Related
Signing in into my firebase app via REST https://firebase.google.com/docs/reference/rest/auth only returns tokens which expire after 1 hour (3600 seconds, according to the REST response). I don't see any way to change this.
Using firebase JS SDK, the authentication persists "forever", which is what I would like to achieve. However I do not want to include the JS SDK in my app, if there is a way around it (mostly because of its size (~700kb)).
Is there a way to obtain a persistent login from the official firebase REST api?
Using firebase JS SDK, the authentication persists "forever"
This is because the JS SDK automatically takes in charge the action of getting a new user's Firebase ID token when the current one expires, by using the refresh token. See the doc.
So you need to implement this mechanism yourself when you work with the Firebase Auth REST API, by using the endpoint that allows exchanging a refresh token for an ID token.
For that you should use the refresh token you received the last time you logged in, e.g. by using the endpoint that signs in a user with email/password, or the last time you refreshed the ID token (see below).
You'll get a response which contains the new Firebase ID token and refresh token. Next time this new ID token expires, use again the refresh token, and so forth...
Current Setup
I'm using cloud functions and the admin sdk for my backend. The front-end is a combination of React, Firebase Auth (web sdk), and redux firebase for authentication. Currently, I force a token refresh for each request for specific components of my react app and save the token to local storage.
Reasoning
Initially, I thought I could simply listen for the auth state to change in my front-end's index.js and then refresh the token accordingly i.e. firebase.auth().onAuthStateChanged A few processes on my app can take quite a while (i.e. uploading content) and I've noticed the change of auth state doesn't get triggered anytime outside of the initial login or a logout.
For example, the user begins to upload content 1 minute before the token is set to expire. The final API requests following the uploading then fail because they finish after the token has expired. The token doesn't get updated and requests fail to my backend as 403 unauthorized. The solution was to use currentUser.getIdToken(true) upon the first load of each of these components. Therefore ensuring a new token is always available.
Problem
Are there security risks to this approach? If yes, how can I mitigate them or is there a better approach to persist the token? I'm nervous about giving users the ability to indefinitely refresh their tokens.
is there a better approach to persist the token?
You're supposed to use onIdTokenChanged to listen to changes in the user's ID token as it changes over time. It works like onAuthStateChanged, except you get fed ID tokens. It's updated automatically as needed by the client SDK. You can store the latest token for use in your calls without having to fetch one with an API call each time.
Are there security risks to this approach?
Not really. Refreshing an ID token is necessary, and the Auth SDK does it automatically internally anyway.
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.
Is firebase token is use to sent to specific device?
How do I store firebase token in MySQL?
From google website, It does not mention about the length of the token.
It seems to be very long.
An Instance ID Token identifies a specific app on a specific device. From the Firebase documentation:
Registration token - An ID generated by the FCM SDK for each client app instance.
The Instance ID Token indeed only expires in very few conditions. Also from the documentation:
The registration token may change when:
The app deletes Instance ID
The app is restored on a new device
The user uninstalls/reinstall the app
The user clears app data.
The token is a relatively long string. Since you're unlikely to frequently search for it, I'd store in in a text field in your database.
I have been using firebase chat and firepad for real time functionality in My Web Application which has multiple pages like a forum.
I started using the Firebase SimpleLogin too.I am able to login as a user and get the auth object which has the uid,id etc info.
1)Now if the user traverses to another page(i.e a new url(same application) is loaded ),does the authentication persist ? Ofcourse as we are manually doing the authentication by calling ref.login(),how can we know if the user is logged in when the second page is loaded.Will firebase store any cookie in user's browser or local storage ?
2)If the user is authenticated through firebase and now for for any request to my backend server for a new page ,how will I know that the user is authenticated.Should I be manually handling this by inserting some cookie in the browser or a hidden form field once firebase login happens ?
3)Is firebase Authentication suitable for multi page web application where the html pages and content are served from a back server other than firebase.?
I have checked the below question too.
Firebase JWT Authentication, Continually Send Token?
As long as browser cookies and local storage are both local storage is available on the browser, Firebase Simple Login sessions will be persisted across page refreshes on the same domain. Simply reinstantiate the Firebase Simple Login client via new FirebaseSimpleLogin(ref, function(error, user) { ... }) to restore a persisted session, if one is available.
Using this approach, your callback will automatically be invoked with the login state of the user. Note that you do not need to call .login(...) again to pick up a session, as calling .login(...) will always try to create a new session.
Once the user is authenticated, you can begin writing Firebase Security Rules, making use of the auth variable, which is non-null for any authenticated user, and will contain useful user information (such as user ids) when using Firebase Simple Login. See the 'After Authenticating' section of any Simple Login auth. provider page to see the exact payload.
In the event that you already have an authentication system you'd like to integrate with Firebase, or Simple Login is not sufficient for your needs, you can always generate Custom Tokens with your own custom data. These tokens can contain any arbitrary JSON payload of your choosing, which will be available in your Firebase security rules under the auth variable.
See the Firebase Security Quickstart for more information.