Access token injection
14A thief can substitute a stolen access token into an implicit response while retaining the client’s valid state.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.6 ↗
RFC 9700 · § 4.6DEFENSE
3 / 3
03
Use the resulting token within its bounds.
Sender constraints and audience checks provide further protection.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Do not accept an unbound front-channel token.
- Pure OAuth implicit flows cannot detect this token substitution through state alone.
- Prefer code flow, as recommended in § 2.1.2.
- OIDC can mitigate injection by validating the ID Token, its at_hash, and nonce. Sender constraints are still needed against direct replay at an API.
State links a response to a browser session. It does not cryptographically bind an access token to that response. An attacker can preserve state while changing the token.
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