Separating renewal from resource access
Clients use access tokens at resources and refresh tokens at the authorization server. Issuing refresh tokens is optional under RFC 6749, so access-token expiration does not create an unconditional right to renew indefinitely.
The separation permits shorter-lived access credentials while keeping renewal on another protected path. Client authentication depends on type and policy; a refresh token is not a universal credential to send to resource services.
References: [1]
Rotation retains relationships between tokens
RFC 9700 requires sender constraints or rotation for public-client refresh tokens. Rotation replaces a token on successful refresh, invalidates the previous value and retains its grant relationship instead of forgetting it existed.
If a stolen token is used by both attacker and legitimate client, one presents an invalidated value. The server detects the problem but cannot identify the attacker solely from that submission; it revokes the active refresh token, requiring fresh authorization.
References: [2]
Renewal remains scoped and revocable
Issuance is risk-based and bound to consented scope and resource servers. Refreshing is not new authorization and must not silently expand limited access into control of the entire account.
Security events can cause revocation, and inactive refresh tokens can expire. Retaining a value longer does not guarantee server acceptance; storage, invalidation and reauthorization determine actual continuity.
References: [2]