Do refresh tokens expire?

[ngerakines]

When a token is minted through either an authorization_code or refresh_token grant type, a token is returned as expected:

{
    "access_token": "tok-4eaa868fb060a0d85e2eb9622b6ee59c",
    "token_type": "DPoP",
    "refresh_token": "ref-b4c7a3ba357ae8c002dd2dd8629e85e0fc43e5efc48331039f610c7280208e55",
    "scope": "profile offline_access",
    "expires_in": 3599,
    "sub": "did:plc:dld7f2usk5v2b2sngw7uapj5"
}

What isn't clear is whether there is an expiration value for refresh tokens. Can you update the spec to include the maximum value in seconds that a refresh token can be used? Also, can that document update include whether that expiration time is fixed or rolling, as in minting a new token returns a refresh token with the same expiration time or one that is also extended past the original refresh token's expiration time?

[bnewbold]

We are still finalizing what the expiration time windows should be:

• whether this should be just "guidance" or hard limits in the spec
• specific values we will have configured by default for the Bluesky-hosted PDS/entryway
• whether these are "rolling" or "fixed" (as you mention)
• how this can best be inspected/discovered by clients

[matthieusieben]

Currently the ATproto OAuth spec require to do what the best current practices recommend:

• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-6.3.2.3

Authorization servers SHOULD link the lifetime of the refresh token to the user's authenticated session with the authorization server. Doing so ensures that when a user logs out, previously issued refresh tokens to browser-based applications become invalid, mimicking a single-logout scenario. Authorization servers MAY set different policies around refresh token issuance, lifetime and expiration for browser-based applications compared to other public clients.

• https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics#section-4.14.2

Refresh tokens SHOULD expire if the client has been inactive for some time, i.e., the refresh token has not been used to obtain fresh access tokens for some time. The expiration time is at the discretion of the authorization server. It might be a global value or determined based on the client policy or the grant associated with the refresh token (and its sensitivity).

So in short, refresh tokens should be expected to expire at any moment in time.

[matthieusieben]

Since we enforce the use of DPoP, using rotating refresh tokens is not really mandatory for authorization server but client implementation MUST be able to support them since that strategy is left at the discretion of the auth server.