Native support for refresh token reuse detection and revocation (OAuth 2.0 Security Best Current Practice)

[JParientePlain]

Do you plan to support the recommendations from section 4.14.2 of the OAuth 2.0 Security Best Current Practices?
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#name-recommendations (Refresh token rotation)

This section recommends detecting replay of refresh tokens and revoking all associated tokens when a token is used more than once, especially when a reuse indicates compromise.

Right now, this kind of logic, I think, can be implemented using a custom ICustomTokenRequestValidator and IPersistedGrantStore, but it would be great to have first-class support for this behavior.

Are there any plans to support this natively in Duende IdentityServer?

[wcabus]

The spec says the authorization server may revoke the access/refresh token when a replay occurs, however it is not mandatory.

If this is a requirement in your setup, it is possible to implement your own ITokenResponseGenerator and register it with the service container (https://docs.duendesoftware.com/identityserver/reference/response-handling/token_response_generator). Another extension point you could use here is the ITokenService where in CreateAccessTokenAsync you could implement some logic to revoke existing access/refresh tokens on replay.

Long story short: this is not included out of the box, but there are some extensibility points you could look at if needed.

[JParientePlain]

Thank you very much for your detailed response.

In our case, we’ve decided to approach this by extending DefaultRefreshTokenService and overriding CreateRefreshTokenAsync, ValidateRefreshTokenAsync and UpdateRefreshTokenAsync.

Do you see any downsides or limitations to this approach compared to using ITokenResponseGenerator?

Thanks again for your help.

[wcabus]

Extending the DefaultRefreshTokenService allows you to have more control over the logic for both accepting consumed tokens (for a period) and detecting replay attacks, as documented here: https://docs.duendesoftware.com/identityserver/tokens/refresh/#replay-detection

Replay detection can be tricky to implement due to potential race conditions. On the server, you'll need a robust synchronization across instances (e.g. using our persisted grant store). On the client, refresh operations will have to be coordinated to not end up with invalid refresh tokens (e.g. when multiple client instances refresh in an uncontrolled way).

This blog post about reusing refresh tokens may also be an interesting read: https://blog.duendesoftware.com/posts/20240405_refresh_token_reuse/