I made my custom backend with nodejs using firebase cloud functions and the auth token expiry time is only 1 hour for the admin sdk how to increase the expiry time of token or something to counter this issue without using the firebase-client in my web app
If you're creating custom tokens you're bound by this requirement that Firebase places on the exp claim:
exp: Expiration time
The time, in seconds since the UNIX epoch, at which the token expires. It can be a maximum of 3600 seconds later than the iat.
You might want to look into session cookies, which (according to the documentation) allow:
Ability to create session cookies with custom expiration times ranging from 5 minutes to 2 weeks.
Related
const router = express.Router();
router.post('/refresh', ...{})
The access token expiration period is 7 days and the refresh token expiration period is 30 days. If 7 days have elapsed, it notifies the mobile app client that it has passed, and the client sends a refresh token to the server to check if the refresh token is valid, and immediately receives a new access token for 7 days and a refresh token for 30 days. It's all right here, right?
But what about after 30 days?? What if the user doesn't log in for 30 days? The refresh token will also expire. And I want to keep sign in forever. (This is the for mobile app, so re sign in is not good for user experience) I don't know what to do at this time.
You have a few options depending on the intended functionality and security requirements of your application.
Change expiry period of one or both tokens, possibly make refresh token infinite to maintain some security
Is background refresh an option you can consider? If this can be completed without the user having opened the app it will work well for you.
Store user credentials and re-login (either automatically or manually) if re-accessing after the refresh token has expired.
I'm using Cloud Firestore for Firebase to store informations about a Rest API Service written in NodeJs.
So, every request to Node will ask to Firebase informations about the service and, for first, it will authorize the request.
I thought that use an user generated JWT will be the best solution because the client have to simply include the JWT in his requests to authorize itself.
A Firebase JWT is related to the uid of the user that generates it.
Obviously, there'll be a control panel where the user can log in with email/pw and generate the JWT, and then the JWT will be included in his client system, for example like simple APIs that requires an API Key to identify the user and to work.
So, the idea appears to work good but i noticed that the Firebase JWTs expire in only 1 hour!
The user have to log-in to the control panel every hour to re-generate the JWT. That's not so friendly.
How can avoid this problem? How can i make the JWT expires in more than only 1 hour?
According to documentation:
The maximum lifetime of a token is 24 hours + skew.
[...]
with a skew of up to 10 minutes.
That means you cannot use these tokens forever, which kind of makes sense.
I looked at custom tokens and found:
The time, in seconds since the UNIX epoch, at which the token expires. It can be a maximum of 3600 seconds later than the iat.
Note: this only controls the time when the custom token itself expires. But once you sign a user in using signInWithCustomToken(), they will remain signed in into the device until their session is invalidated or the user signs out.
Perhaps you can do something with the signInWithCustomToken() as once logged in it expires only when the user is invalidated or signs out, but I believe the best course of action would be to look for another approach.
I am facing token expire issue every 20 to 40 mins but actual time is one hour but I need a token validity one day.
Please help me.
This is not possible to change the token validity period with AWS Cognito User Pools. Currently, its fixed to 1 hour.
I am using library 'jsonwebtoken'(jsonwebtoken) in node app for generating JWT. But my requirement according to the business is forcefully invalidate isuued JWT to a user when he/she logs out. Is there any method like jwt.expire(...) or any other jwt library which supports forceful invalidation
Now in my application I have set expiry time for token as 1 hour and token is saved in DB for each user login.If a user logouts before 1 hour token is invalidated in DB. But if an external user identifies the token he can access our resources in the areas where we are not checking DB token invalidation(In many areas we are using method jwt.verify(..) which succeeds till token expiry time 1 hour). My requirement is jwt.verify(..) method for the token should return invalid if the user logs out before 1 hour.
I'm fairly new to token based authorization. I'm trying to find the flaws in a custom expiration/token-refresh scheme.
I have a basic JWT auth setup in an Express API; I'm setting the JWT expiration to 1 hr; However, JWT checks token expiration relative to the time the token was issued. I would prefer that the expiration time gets reset after each successful api call. If my user is actively using the app for more than an hour, I don't want them to have to log back in to refresh the token (and possibly lose whatever data they are working on.)
On the the other hand, I do want the token to expire if they are not responsive for more than an hour.
I have come up with the following approach:
During every successful API request, issue a new JWT and send it in a
custom response header. My client side code is responsible for
checking this JWT response header and using its value as the new default Authorization request header. Thus, if there is no API
request from the user for more than 1 hour, the token will expire and
not be refreshed. Login would then be required. In addition, the original issue-date of the token (timestamp of login-authentication) will be stored so that a "hard-expiration" of the token will be enforced after 24 hours.
This seems fairly straightforward and reasonably secure, but I haven't seen any reference to it in my JWT research. Is there a better way to achieve the same goal? Am I missing a major security hole with this approach?
UPDATE:
After thinking of this for some time, I realized that the problem with this is that it opens the door to replay attacks that could not be thwarted by token expiration. So there should absolutely be a "hard-expiration" check: hard expiration would invalidate the token at some time after issue date, regardless of recent user activity.
Here you can check my answer for this scenario:
implementing refresh-tokens with angular and express-jwt
What I have done is to have a time window where the server checks if the token expiration and the local server time is in this window and then send a response header with the refreshed token.
If you agree and realize that you need a hard expiry time anyhow, why not set the expiry time of the (one and only) access token to that and stick to plain OAuth 2.0? An asymptote of what you're doing now, would be to issue your own API specific token/cookie after first use of the access token (in the API response) and enforce subsequent API access based on that. That is a valid approach, but duplicates a lot of stock OAuth 2.0 Authorization Server functionality in your own API. I don't see a good reason to go there.