Guidance on Refresh Token Rotation

[jbasney]

https://www.rfc-editor.org/rfc/rfc6819.html#section-5.2.2.3 says:

Refresh token rotation is intended to automatically detect and prevent attempts to use the same refresh token in parallel from different apps/devices. This happens if a token gets stolen from the client and is subsequently used by both the attacker and the legitimate client. The basic idea is to change the refresh token value with every refresh request in order to detect attempts to obtain access tokens using old refresh tokens. Since the authorization server cannot determine whether the attacker or the legitimate client is trying to access, in case of such an access attempt the valid refresh token and the access authorization associated with it are both revoked.

The OAuth specification supports this measure in that the token's response allows the authorization server to return a new refresh token even for requests with grant type "refresh_token".

Note: This measure may cause problems in clustered environments, since usage of the currently valid refresh token must be ensured. In such an environment, other measures might be more appropriate.

CILogon currently implements this. We've found that some clients ignore the new refresh token and try to keep using the old refresh token, which I believe is a violation of https://www.rfc-editor.org/rfc/rfc6749.html#section-6 which says:

The authorization server MAY issue a new refresh token, in which case the client MUST discard the old refresh token and replace it with the new refresh token. The authorization server MAY revoke the old refresh token after issuing a new refresh token to the client. If a new refresh token is issued, the refresh token scope MUST be identical to that of the refresh token included by the client in the request.

Since I think the IAM default behavior is to never expire refresh tokens, the clients can ignore the new refresh tokens and still work successfully against IAM, which may cause problems when WLCG configures IAM to implement the 30 day maximum lifetime on refresh tokens as specified in the profile.

See the March 2022 thread about "Refresh token lifetime, renewal, revocation" on project-lcg-authz@cern.ch for additional context, including a discussion of current oidc-agent behavior.

It'd be helpful if the profile addressed the following topics:

1. If the token issuer does not implement Refresh Token Rotation, what happens when the refresh token expires in 30 days? Does the client (e.g., robot) need to do a new authorization code flow?
2. If the token issuer implements Refresh Token Rotation, is the new refresh token valid for another 30 days from the date of issuance (i.e., the lifetime of the chain of refresh tokens can be extended indefinitely)?
3. If the token issuer implements Refresh Token Rotation, what happens if the client fails to use the new refresh token and continues to use the old refresh token? Should the refresh tokens be immediately revoked or should there be a grace period (for clustered environments or client-side token synchronization failures)?

[giacomini]

Re-reading https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.13 (Refresh Token Protection in OAuth 2.0 Security Best Current Practice, still a draft), however, refresh token rotation is specifically recommended for public clients. See also https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-05#section-4.3 (Refresh Token Grant in The OAuth 2.1 Authorization Framework, again still a draft). This is not to say that refresh tokens should not expire also for confidential clients, but there is no need to be very aggressive.

[paulmillar]

I opened an issue against oidc-agent, to clarify it's support for refresh token rotation.

Gabriel gave an extensive and detailed reply, providing information on what is possible right now and what might be possible in the future.

I won't try to summarise the information beyond saying "it is possible to support RT rotation right now", which (I think) goes against perceived wisdom. The interested reader is invited to peruse the above issue for more details.