[OAUTH-WG] Re: Refresh Token Rotation

[David Waite <[e-mail]>]

On Aug 2, 2024, at 5:36 AM, Indeewari Wijesiri <[e-mail]> wrote:

> Hi Warren,
> 
> Thank you for your attention.
> 
> When public web clients use the authorization code grant for authentication, a successful response includes an access token and, optionally, a refresh token. If the access token is a JWT rather than an opaque token, the identity server will issue a new JWT access token for each authentication request with the same client_id and scope, based on the "issued at" (iat) claim. This means each authentication attempt generates a new JWT access token.
> 


Each interaction with the authorization endpoint with the user MUST generate a new authorization code when using code grant type. An authorization code MUST be short lived and single-use.

Beyond that, it is expected that servers have their own policy. There’s no requirement they do refresh token rotation or support refreshes at all. There is AFAIK no requirement that the new access token be different than a previous access token, on grant or refresh. These are all policies for the AS to implement.

Refresh token rotation (and making sure you issue new access tokens on refresh) is effectively using the refresh token mechanism as a way to detect cloning. If someone exfiltrates the access token (or even the access and refresh token) and uses them independently, eventually the two clients will be out of sync, and the server will have visibility that there are potentially multiple “clients” using the tokens.

The queued security topics BCP ( https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ ) and the BCPs for native applications and in-progress one for browser-based applications are likely the best resources here for policy recommendations for AS implementations/deployments. There are some cross-cutting recommendations for all clients, but there may not be a best-fit policy if you have client diversity (say, browser-based applications, smart tv and set-top box applications, and third party hosted services needing long-running data access)

Another way of looking at it is that a client is being authorized for delegated access for a period of time; you can represent that as a single access token, a series of access tokens created off of a single refresh token, or a series of access and refresh tokens. These could all effectively give the same access over the same period of time.

Business and security/risk policies at the AS make this decision opaquely; different clients might get tokens with different behaviors, and tokens with different behaviors may be created by the scope or resource being requested. The BCPs provide guidance to help the AS understand appropriate security and risk decisions.
> In this context, how should the refresh token behave? Is it advisable to use a long-lived refresh token in conjunction with the JWT access token, or should the refresh token be rotated each time a new JWT access token is issued?
> 

The browser-apps BCP (as an example) indicates that if you do, they MUST either rotate on each refresh or that the refresh tokens be sender-constrained (through a mechanism like DPoP). It requires certain token lifetime policies be in place, but does not give mandates on what these lifetimes should be (e.g. 4 hours or 4 years). This advice comes from the higher risk of token exfiltration in the browser environment when the credential is held within local storage which is easily readable by javascript or the user.

I don’t expect it is common policy for a new access token (issued outside a refresh, e.g. code grant) is associated with an existing authorization grant. 

A browser-based client or native app client can have multiple concurrent authorizations, because the end user may have multiple browsers/devices. These sorts of “client instances” usually don’t have a way to be individually identified, so (from the AS perspective) they have a lifetime of the token validity. If a client does a code grant, there’s no way (in the core protocol) to identify as a that being related to a previous grant.
> For opaque access tokens, since they are not renewed with each request, a long-lived refresh token can be used.
> 
I am making an assumption that by ‘opaque access tokens’, you are speaking to requiring a resource server to use an interface like the token introspection endpoint to determine validity and purpose, rather than introspecting the token contents based on some known format like RFC9068. 

All access tokens should be effectively opaque to clients, so whether a token is opaque or parsable doesn’t affect malicious clients having authorization. Access token interpretation is set between resource servers and the AS.

-DW