This is how I do my JWT refresh token:

A token is check for validity every time a request is made. If it's not expired, allow access.

If it's expired calls another function named RefreshToken to give a new token to the user.

Ok this mechanism is good enough except that every expired token (of that user, provided that it is valid) can fire up the creation of a new fresh token.

For example
Expiration is at 15 minutes.
Token A is created.
Token A asks for a new refresh token after 1 hour.
New token is issued, named Token B.
After 15 minutes, Token B is expired.
Now, Token A and Token B can ask for a new token.
Wouldn't that create the ability to issue token exponentially?
Just from 1 token.
And the token can issue another token and so on. An expired token 15 years ago can issue a new refresh token today even though it was used some time in 15 years ago and had issued another token too.

enter image description here

Now every token issued can create another token. Can I just allow Token A --> Token B --> Token E without storing expired token into database?

Order of token alphabet takes precedence

  • Allowing any expired token to be refreshed is equivalent to not expiring tokens at all. – Jack Jul 13 '16 at 16:22

In token based auth systems, a common pattern is to differentiate between short lived tokens and long lived tokens. Short lived tokens are used for all API calls and expire quickly. Long lived tokens are only used for retrieving short lived tokens, and their exposure to other environments is minimized.

When a user first logs in, they get a long lived token that is stored in the browser somehow and never used except when they need a new short lived token. The short lived tokens are used for all calls. The system can keep a record of all issued long lived tokens to allow administrators to force-expire long lived tokens. This is basically how "remember me on this device" features work. You can go further by using the long lived token to generate multiple short lived tokens, each valid for a different 15-minute window of the next hour or so. Long lived tokens also allow for separation of concerns, because everyone can check the validity of short lived tokens but only a specific auth service can be allowed to generate new tokens. Clients would only ever send their long lived tokens to that auth service, minimizing the possibility of network eavesdroppers stealing the token.

However, if expired short lived tokens can be refreshed with just the token, they effectively do not expire. Who cares if a token expires after fifteen minutes if all you have to do is call some refreshing service with just the token and you get a new one? It destroys the security of token expiration, the whole point is that after credentials expire you need some stronger form of authentication to reissue the credentials.

  • how would you implement this specifically in JWT? The long lived and short lived ones. I see them both as the same. If I don't have short lived tokens, I can still refresh using the long lived ones since the long lived ones will generate new tokens valid for 15 minutes.. "Clients would only ever send their long lived tokens to that auth service, minimizing the possibility of network eavesdroppers stealing the token." Why don't just send the short lived tokens to the auth service to refresh it? – momokjaaaaa Jul 30 '16 at 11:39
  • JWTs can contain claims, which you can use to make different kinds. Your long lived JWTs are simply those which claim they're long lived in the payload. It's up to whatever auth service you're using/creating to generate long lived tokens with that claim. When attempting to refresh tokens, the auth service should verify that the token you're using to authenticate has that claim. – Jack Jul 30 '16 at 18:54

One of the ideas behind the OAuth system is that the resource provider can check the validity of your auth token and read its claims but NOT issue you a token itself. For that you need to go back to the auth provider and request one with either your username/password or your refresh token.

if your resource providers automatically issue a new token when they recive an expired auth token, effectively you ha e no expirey.

Plus resource provider 2 will have to trust resource provider 1 rather than just the auth service

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.