Lexikjwtauthenticationbundle: Question about token ttl expiration.

Created on 28 Apr 2015  路  11Comments  路  Source: lexik/LexikJWTAuthenticationBundle

The ttl token, starts to count after the last request and if one request is done the token ttl is renewed? or ttl counts form the last login ?

Thanks

Regards

Most helpful comment

No that bundle does not extend the lifetime of the token.
It adds a flow to issue new tokens with user interaction.

When the bundle is installed an configured, your client will receive 2 tokens:

  • the token you already receive and that you use for your API calls,
  • a refresh token to issue new tokens.

At the moment, your client acts as below:

  1. Your client calls the API,
  2. The call is rejected because the token expired,
  3. Your client redirect the user to the login page and get a new access token,
  4. Your client calls the API and is granted

With the refresh token enabled, the step 3 is Your client calls the refresh token endpoint and get a new access token.

All 11 comments

Hi,

The token is only generated after the form login, there is no concept of "refreshing" or "renewing" in JWT. The TTL is part of the signature so you cannot update it without invalidating the token.

Once the token has expired you must generate a new one, either by asking for the user credentials or programatically.

Regards.

@slashfan Thanks.

I saw that I can create new one with create method from JWTManager.

But How I can generate programatically new token when it has expired ? Because if token is expired I don't know If it is correct....

Thanks

Hi, the only way I can think of would be to bypass the expiration checking, but I wouldn't recommand it.

ok, then I'm thinking to generate new token every x time, and return allways the token in every request.

There is some method to remove the old token ?

Thanks

It could work, you can change the ttl too, or configure your client application to ask for a new token periodically.

For the token invalidation, look at this cookbool entry and the IP flag examples, you should be able to customize the token validation by using the Events::JWT_CREATED and Events::JWT_DECODED events.

For example, you could configure an application wide key or hash, add it to the token payload and change it when you want to invalidate every token in the application.
If you just want to invalidate a specific user, store a user key directly in the user entity and change it when neeeded.

Hi, I'm having trouble with the token validity.
I'm using the default token_ttl value, but users have to re-connect too often.
Can nelmio_cors "max_age" parameter interfer with the ttl_value and result in such an issue ?
Any idea ?
Thx

The CORS will not help you in this case. When a token expires you have to issue a new one.
Using the gesdinet/JWTRefreshTokenBundle, your client will be able to renew a token with a refresh token.

Thank you for reactivity.
You mean that I need to install whole of another bundle just in order to make token last longer ?
I must be missing something :(

No that bundle does not extend the lifetime of the token.
It adds a flow to issue new tokens with user interaction.

When the bundle is installed an configured, your client will receive 2 tokens:

  • the token you already receive and that you use for your API calls,
  • a refresh token to issue new tokens.

At the moment, your client acts as below:

  1. Your client calls the API,
  2. The call is rejected because the token expired,
  3. Your client redirect the user to the login page and get a new access token,
  4. Your client calls the API and is granted

With the refresh token enabled, the step 3 is Your client calls the refresh token endpoint and get a new access token.

@stphane What about first setting the token_ttl with a greater value than the default one? Then, if you really need a refresh token mechanism for avoid requesting a new token from credentials, yes the solution proposed by @Spomky stay your best alternative, not from the bundle perspective, but in JWT in general.

Thank you for details and advices.
By "reconnect to often" I meant like every 5 minutes.The default value of 84600 should cover an entire day right!?. I now suspect the appGyver developer to not join the token along some requests from inside the mobile application which cause itself to prompt its login form.
I will let you know once the developer has inspected his code.

Was this page helpful?
0 / 5 - 0 ratings