Open redirection
19A URL on a trusted client or authorization server can bounce the browser to an arbitrary phishing or exfiltration endpoint.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.11 ↗
RFC 9700 · § 4.11DEFENSE
3 / 3
03
Continue only through a controlled handoff.
Exact callback matching remains necessary.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
Read the updated RFC section ↗
Control the destination of every redirect.
- Clients MUST NOT expose open redirectors. Allow intended destinations or authenticate request origin and integrity.
- Authorization servers MUST NOT auto-redirect invalid client_id and redirect_uri combinations.
- Servers MUST take phishing precautions, authenticate first with the silent-authentication exception, and SHOULD auto-redirect only to trusted URIs.
Even a correctly registered redirect URI can be a phishing destination. Errors, consent denial, or silent authentication can otherwise turn an authorization server into a credible-looking bounce point.
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