1

I've read through this explanation of refresh tokens here: https://stackoverflow.com/a/36280559/11634814 and I think it makes a lot of sense. In a nutshell, refresh tokens are useful because you only have one unexpired access token associated with each refresh token at a time. If Bob has stolen Alice's refresh token, we can detect this because he'll try and use it to make a new request with Alice's token, even though Alice's access token is not expired.

Trying to make a request with a refresh token when the corresponding access token is not expired is odd, and the server can detect this and invalidate the refresh token. My question then is very similar to this question asked in the comments by @Rakib:

"Does the server has to maintain a state for refresh token to find the anomaly? If yes then using a refresh token is not stateless implementation. Is that a current assumption?"

Does this implementation mean that you would have to store the current access tokens that are associated with a single refresh token? Or is there a stateless way to go about it?

Thanks

Evan
  • 1,892
  • 2
  • 19
  • 40

1 Answers1

1

No limits for refresh_token exchange

I used refresh_token from google and aws without any restrictions. I mean, I was able to obtain a new access_token using the refresh_token many times in an interval less than expiration time (3600s for google).

Also, according to the section 10.4 spec, auth0, microsfot and this the refresh_token has no endless life, quite the contrary could expire or be invalidated.

So, to flag a refresh_token as invalid or suspicious just taking into account the existence of non-expired access_token, would deprive you of a useful feature.

Stateless authentication

If you are using JWT and your security features are in another artifact (authorization server), not inside of your microservice artifact (resource server), we can say:

JSON Web Tokens (JWT) are referred to as stateless because the authorizing server needs to maintain no state; the token itself is all that is needed to verify a token bearer's authorization.

No state in simple terms means that does not exist a kind of live session in the server (authorization server in your case) related to the main entity or event (token in your case). In more simple terms, you can restart the server and nothing will be lost and previous generated token will continue to work

So if your concern is the refresh_token theft or some abuse of access_token generation, you should implement a logic in your authorization server.

In that case, your authentication will remain stateless because that logic will be in a table or another mechanism, and the final feature remains the same: Just the token is required and there is not a live session attached to the token in the authorization server.

Finally the best known authorization servers or iams(auth0, okta, keycloak, google, aws, microsoft, etc) continue to offer a stateless authentication regardless of the large number of features (access_token/refresh_token generation, token revocation, users management, etc ) and the required complex software components and strategies that work in background.

JRichardsz
  • 14,356
  • 6
  • 59
  • 94