Misuse of stolen tokens
18Combine proof of possession with audience checks so a stolen token cannot travel freely between callers and APIs.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.10 ↗
RFC 9700 · § 4.10DEFENSE
3 / 3
03
Reject a token intended for another API.
Server-side audience enforcement complements the sender constraint.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Constrain both the sender and the destination.
- mTLS or DPoP can bind token acceptance to a sender’s key; audience restrictions limit where a token works.
- To prevent resource-server phishing, bind the audience to the actual destination URL or another suitable concrete binding.
- § 4.10.3 discourages relying only on client-enforced destination allowlists advertised in metadata.
If the attacker controls the client’s proof key too, sender constraints may fail. Audience checks cannot protect resources on a fully compromised server. Defenses reduce particular capabilities, not every breach.
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