Prevent token replay
04A copied credential should not automatically grant a second caller the same access.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 2.2 ↗
RFC 9700 · § 2.2DEFENSE
3 / 3
03
A stolen token alone fails.
The thief does not have the key needed to demonstrate the required proof.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 6 and 10.3RFC 9700 § 2.2
The BCP recommends sender-constraining access tokens. Public-client refresh tokens must be sender-constrained or rotated to detect replay.
Read the updated RFC section ↗Make stolen tokens harder to reuse.
- Authorization and resource servers SHOULD sender-constrain access tokens, using mechanisms such as mTLS or DPoP.
- Refresh tokens for public clients MUST be sender-constrained or rotated.
- Confidential-client refresh tokens remain bound to the client they were issued to.
Sender constraints reduce replay; they cannot save a client whose token and proof key are both compromised. DPoP and mTLS use different proof mechanisms.
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