For firebase, I'm using custom authentication because our organization uses CAS for single sign on.
Does custom authentication handle refresh jwt tokens automatically or would I need to develop a refresh workflow within my app?
I am not creating custom tokens using a third party library. My token is created via var token = firebase.auth().createCustomToken(uid, additionalClaims) as described on https://firebase.google.com/docs/auth/server/create-custom-tokens. But this page doesn't mention anything about refresh tokens.
My clients are mainly web, and I've found notes that if you use the Android SDK, this refresh happens automatically. But I'm unsure about refresh tokens and web clients for custom authentications.
After you create the custom token using createCustomToken, you pass that token to the web client and call firebase.auth().signInWithCustomToken(token). The promise returned will resolve with a firebase User. The onAuthStateChanged listener will trigger as expected. A firebase Id token will be available. The token will be refreshed every hour and will be handled by the Firebase SDK. Anytime you call a user method or getToken on user, the token will be automatically refreshed if the old one was expired.
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 have following use cases:
I have cloud functions which are accessible with HTTP endpoint and they use authorization using custom token because the app is only accessible with certain IPs stored in RTDB so I have created one cloud function with will generate a custom token after signing in user using firebase client SDK and then it will create a custom token using admin SDK after checking IPs which are stored in RTDB.
Now with every subsequent call client will send token and functions will serve the request.
I have event listeners bound with the RTDB on a client and use file upload using client SDK which client initialize with firebaseApp.auth().signInWithCustomToken(custom token).
On the function side I use the same sign in the method that also utilizes my firebase SDK and then I serve that request. The problem here is this sign in the method is very slow like it is taking generally more than 1 second only in sign in.
Alternative
Now alternative is I can use id token which can be created using currentUser.getIdToken() on the client side itself and it takes barely few ms to decode that token but I cannot initialize SDK with that token. so I have to use admin SDK but my IP node in RTDB is not accessed by the normal user and can only be accessed with admin SDK, so if I use ADMIN SDK with Control Access with Custom Claims and Security Rules to give admin SDK similar access that the authorized user has then IP node will not be accessible.
Issues with id token
Id token can be refreshed on the client side so once a client has a custom token, It can generate as many tokens it wants and that is not desirable. Apart from that validating IP everytime is not the operation that I wanted to do so with custom token I only use that in generating a custom token and then for a refreshing token but with id token, this would not be possible as the client can generate it with SDK.
Basically, I have to use firebase SDK on the client side which will need custom token(for additional authorization check) to initialize and at the same time I call the clound function from the similar app so what is the best way to implement this use case.
I implemented Auth with Firebase + Facebook. To be able to use the Auth with my custom backend I implemented the admin SDK on my node Server. Now I am trying to validate if my Firebase token is still valid to know when I need to show the login screen. I could probably send the token to my custom backend. But since I don't need anything else from the backend, it would be easier to directly call firebase from the client.
Does someone know if a function like that exists?
Firebase client SDKs periodically refresh the ID tokens and keep them alive. Therefore the token will remain valid, until the client explicitly invokes a sign out operation. See this discussion for more details: https://groups.google.com/forum/#!msg/firebase-talk/rjR0zYiiEhM/Clt9aFtgAwAJ (It is a little old, but still relevant
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.