Refresh token protection
22Refresh tokens can mint future access. Rotation makes reuse visible; sender constraints make possession alone insufficient.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Stop further refreshes and require a new authorization grant.
Public-client refresh tokens need replay protection. Rotation invalidates the previous token, retains its relationship, and revokes the active refresh token when reuse is detected.
Read the updated RFC section ↗Bind or rotate. Detect and stop reuse.
- Servers MUST risk-assess refresh-token issuance and bind issued tokens to consented scopes and resource servers.
- For public clients, servers MUST use sender-constrained refresh tokens or rotation to detect replay.
- With rotation, invalidate the previous token and retain the relationship. Reuse triggers revocation of the active refresh token. Tokens SHOULD expire after inactivity.
Rotation does not identify the thief: either the client or attacker can present the old token first. Detection revokes the active refresh token and requires a fresh grant. Security events such as logout or password changes MAY also trigger revocation.
Read the RFC section ↗Diagrams simplify the RFC. Read the linked sections for complete requirements.
PrivacyAll chapters in this RFC
- OAuth overview
- Authorization code + PKCE
- Retire unsafe grants
- Prevent token replay
- Limit token privileges
- Authenticate the client
- Metadata, TLS & CORS
- The attacker model
- Redirect URI validation
- Referer header leakage
- Browser history leakage
- Authorization server mix-up
- Authorization code injection
- Access token injection
- Cross-site request forgery
- PKCE downgrade
- Leakage at resource servers
- Misuse of stolen tokens
- Open redirection
- 307 credential forwarding
- TLS termination & proxies
- Refresh token protection
- Client as resource owner
- Clickjacking
- In-browser messaging