The attacker model
08Attackers can run their own services, control a network, observe OAuth messages, or obtain a token. They can also collaborate.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 3 ↗
RFC 9700 · § 3EXAMPLE
3 / 3
03
Leaked messages and tokens extend the threat.
A3 observes responses, A4 observes requests, and A5 obtains tokens. Model the combinations.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Design for the environment you actually have.
- A1 can operate browsers, clients, authorization servers, resource servers, and lure users to chosen URLs.
- A2 can observe, modify, spoof, or block network traffic, except where cryptography protects it.
- A3 reads authorization responses; A4 reads authorization requests; A5 acquires access tokens. These can combine with A1 or A2.
This is a minimum model. Implementers MUST account for other attackers relevant to their deployment. An attacker may also be a legitimate resource owner with their own account.
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