Leakage at resource servers
17A counterfeit endpoint or compromised resource server can collect access tokens and attempt to use them elsewhere.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.9 ↗
RFC 9700 · § 4.9DEFENSE
3 / 3
03
Reject cross-server replay.
The honest API validates its audience and, when used, the sender proof.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Protect tokens at rest and limit their replay.
- Resource servers MUST treat tokens as sensitive secrets and MUST NOT store or transfer them in plaintext.
- Sender-constrained tokens and audience restrictions SHOULD limit reuse at other servers.
- Secure resource configuration matters; a fully compromised server can still access its own resources.
The RFC distinguishes token phishing from server compromise. Standard system hardening is outside this document; the focus here is limiting OAuth token fallout.
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