How to set refresh token expiration time?

How to set refresh token expiration time?

1 Like

Same please check the docs

I was looking at documentation, but I did not find anything talking about the lifetime of the refresh token, just the token.

AdonisJs provides additional options. Set the expiresIn to set the expiration time.

See Table 1. Additional Options

Ex.

{
  authenticator: 'jwt',
  jwt: {
    serializer: 'Lucid',
    model: 'App/Model/User',
    scheme: 'jwt',
    uid: 'email',
    password: 'password',
    options: {
      secret: Config.get('app.appKey'),
      expiresIn: 86400,
      algorithm: HS384,
      ...
    }
  }
}

Hope this helps :smiley:

Hello, about the expiresIn I have actually seen it, but it seems to me that it has no effect. Do not update token and even if I have a half incoherent the token and the refresh token have the same lifetime. I know that in Laravel it is possible to configure a lifetime for the token and another lifetime for the update token. I may be wrong, but I think there should be a way to configure the update ring time and a lifetime for the token itself.

Refresh tokens doesn’t expire. There are saved inside the database and you have to revoke them or delete them

1 Like

Here it is in action.

Also, you are correct. Laravel Passport does allow one to set the expiration of a refresh token using the ** refreshTokensExpireIn()** method, but not sure in AdonisJs’ case.

It appears as though AdonisJs is using Auth0’s JWT package.

Also, it doesn’t look as though it allows for an expiration on the refresh token; however, poke around in Auth0’s repo. Have fun!

Hope this helps :smiley:

Now, this comment saved me. I was thinking that what was saved was not the database and update too. Now I’ve even found a solution for this TOPIC that is active. Thank you very much.

Okay, thanks for your example.

When you check on the table tokens you can see the created_at and updated_at.

I also had the same problem and i resolved it by having a cronjob which i could run and set the is_revoked to 1 to refresh tokens that the last updated_at as maybe 24 hours or your preferred refresh token duration.
That will automaticaly revoke a refresh token.

I don’t get what’s the point of expiring the refresh token. Read more here https://auth0.com/learn/refresh-tokens/

@virk Right in the link you sent, in the bullet list under the “Using Refresh Tokens” section, it specifically says “the refresh token has expired” as one of the reasons the refresh token may no longer be valid.

The server uses the access token to generate a new refresh tokens and determines the expiration of the later one. The implementation of how this 'expiration functions differ from a framework to an other. In this context, I think someone of us should document how AdonisJs tackles this implementation.

I just wanted to give a work around that I have implemented in my project:
In the controller method for getting a new access token via a refresh token I fetched the created_at timestamp of the provided refresh token from the database. Then, checked if the current time has surpassed the created_at timestamp + the length of your expiration. I used moment-timestamp npm package for checking, and I stored the refresh token expiration time as an environment variable. If the current time has not surpassed the refresh token creation date + expiration time, I sent a new access token, otherwise I revoked the refresh token and sent an error message, which then the front end redirected to the login page.

As a side note, due to the insecurity of stolen refresh tokens, as an extra precaution, I added a new table token_metas with the users ip address and use-agent and also revoked the refresh token if, when requesting a new access token via refresh token, the ip and user agent was different.

Hope this helps anyone looking to use refresh token expirations in adonis!

1 Like

I like your idea of using the refresh token as an environment variable. I think it is better than dedicating a relational table for it (which has to be associated with the pre-existing tokens table)

However I do not see benefits in the complexity you added through the paragraph 2 because a request made using a refresh token should require authentication (email + password, for example), and thus if an attacker gets access to the refresh token only, it is a useless attack for him. @Secular12

An other information: RFC 6749 says refresh token expire, by the way.

Most likely the way you implemented the process is the issue. I say so because I had a similar issue with one of my applications, and I found out the way I designed the solution was the culprit.

EDIT: @begueradj I did later update this to not have the unnecessary token_metas table. I just added the ip and user_agent columns to the tokens table. I also encrypted the ip address, for the user’s privacy. Finally, I also added the ip and user_agent to the access token as well to also catch suspicious activity whether using the access token or the refresh token. If either looked suspicious I’d return an error message and revoke the refresh token.

1 Like

Well, the RFC says Refresh Token expire too. They have a longer life than the Access Tokens, but they expire.