Refresh Token Rotation

[tafli]

Single Use Refresh Tokens

Problem

As for now a refresh token can be used to refresh a JWT as many times as long the refresh token is valid and not retracted.

Regarding security considerations, I'd like to have a refresh token, that can be used to refresh a JWT only once.

Solution

The refresh response must return next to the new JWT a new valid refresh token. The used refresh token must become invalid immediately.

The applications security configuration must offer to use single use refresh tokens.

How to vote

Please give us a thumbs up or thumbs down as a reaction to help us prioritize this feature. Feel free to comment if you have a particular need or comment on how this feature should work.

[robotdan]

If you want a single use token, why not just use the JWT?

Can you describe a use case where you want FusionAuth to issue the JWT as a result of authentication, and also issue a Refresh Token for a single use?

[tafli]

@robotdan : I guess, there is a misunderstanding. Please correct me, if I'm wrong.

The result of authentication is having a access token (AT) and a refresh token (RT). The AT is used to access the secured resource and has a rather short live span.
The RT cannot be used to access the resource but for a client to refresh a AT without having to interact with the actual user. Therefore the RT has a long lifetime and mast be kept as secure as possible.

In case a RT is somehow leaked, an attacker can use the RT to get an AT to access the protected resource. And as the RT can be used multiple times, the leakage probably stays undetected.
Now:
When a RT act as a one time token, the real client is logged out on the next AT refresh (as the RT has become invalid) and must force a user to redo a login. In such a case, the old RT must/will become invalid and a new RT is generated along the AT.

In this scenario, when using a refresh token to get a new AT, it must also return a new RT as well and all possible other RTs from this user must become invalid.

Ofcourse there are config possibilities, e.g. a definable number of times a RT can be used or how long a RT is valid.

[robotdan]

Ah, ok, got it. I think you're asking for a rolling refresh token, or sometimes called refresh token rotation.

This is something we're looking at already. Here is one of the recommendations that is being made in the 2.1 draft spec. Does this description sound like what you're after?

Refresh token rotation: the authorization server issues a new refresh token with every access token refresh response. The previous refresh token is invalidated but information about the relationship is retained by the authorization server. If a refresh token is compromised and subsequently used by both the attacker and the legitimate client, one of them will present an invalidated refresh token, which will inform the authorization server of the breach. The authorization server cannot determine which party submitted the invalid refresh token, but it will revoke the active refresh token. This stops the attack at the cost of forcing the legitimate client to obtain a fresh authorization grant.

https://tools.ietf.org/id/draft-parecki-oauth-v2-1-00.html#name-refreshing-an-access-token

[tafli]

Yes, refresh token rotation is exactly the thing, I'm after but didn't know how to name it. Great to hear, you're already looking into that one.

[robotdan]

We can leave this issue open and use it to track the feature.