I have no issue with my firebase token expiring but I'd like to programmatically know about this so I can ensure the UI responds in an appropriate way when this happens.
In this situations I notice that I get the following message:
resumeSession() was canceled: Auth token is expired.
How can an Ember SPA hook into this event?
Related
I'm using directus to grant users access to ressources required by an SPA written in Angular. To authenticate users I created an auth service and interceptor to handle sessions and attach the "Authorization" header. Those services work fine and login as intended. But here comes the problem:
Directus session times are configured with default values (15 min validity for access_token, 7d for refresh_token) but as soon as the access_token expires I cannot retrieve a new one using the refresh token. This bugs me, because the goal is to keep users logged in for the next 7d (refresh_token lifespan) or until logout if they check this option.
My attempts at achieving this:
Since i'm using graphQL, i tried the "auth_refresh" mutation from the authentication documentation. While the access token is still valid, refreshing works fine. After the access token expired there is no way to retrieve a new one via a valid refresh token.
Alternatively I tried to achieve a refresh via the POST request specified by the docs (to double check if it was some sort of config error with graphql) but I encounter exactly the same problems as with graphQL. Directus returns either "401 unauthorized : Token expired."
if i extend the lifespan of the access token for longer than the server defined lifetime,
Response: Sending a token with prolonged life
or "401 unauthorized : Invalid user credentials." if I request a new token without an
"Authorization" header.
Response: Sending no access token
The refresh token is correctly loaded and sent to the server as specified in the docs in both
cases.
Now my questions are:
Am I missing something? I haven't found any further specification in the docs and the Auth0 protocol specifies that a new access token should be retrievable with a valid refresh token.
If this feature is not intended: How could I achieve a "keep me signed in" option with directus? I would like to keep user rights management in one place and do not really want to handle user auth redundantly for my current use case.
2b. Why is the lifespan of the refresh token so much longer than the lifespan of the access token if this isn't intended?
One of my thoughts is, that it has to do with access rights of the "public" role on the "directus_sessions" table. But I can't think of a way to grant only read rights for owned/received tokens, since there are no payload variables available inside the filters. Could this be the cause? Would there be a way to achieve this?
Thx&Greetz
I can not find how should handle the auth part correctly. Basically, my backend returns me a token, and with this token, I call auth().signInWithCustomToken(token). All works fine my users have access to chat and other things. Also, on signout I call auth.signout(). But the problem is if the user does not use the app for some time and when coming to the app with refresh token if it is valid we generate new accessToken. But how to handle firebase part in this flow because user can not access chat, etc because it seems firebase token is not valid anymore. Any idea how to handle refresh token or flow in this case?
Once you've signed out with signout(), refreshing a token won't help at all. The user is fully and completely signed out. If you want to sign back in, you will need another new token to sign in with signInWithCustomToken(). Once the user is signed in, the Firebase SDK will automatically refresh a token to keep that sign-in alive for a long as needed. There is nothing you need to do for that.
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.
As I found out in Firebase source, every token has an expiration time of one week. And because messaging().onTokenRefresh is not implemented now, I'm assuming that there is no way of sending webpush-notifications to users that haven't been on my website with configured FCM for a week or longer.
Or my assumption is incorrect and this expiration exists only on browser side? And tokens on the server-side of FCM aren't expiring without a call from browser to recreate token?
It's not an actual expiration, but just a way to update the token information on Firebase servers. If the token is still valid (and it most likely is), updateToken method will return the same token, and it will keep working.
If you get a different token after a getToken call, you can safely overwrite the previous token in your server.
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.