JWT refresh token exponentially?

Question

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.

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

Answer 1

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.

Answer 2

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