307 credential forwarding
20After a login POST, a 307 redirect preserves the method and body, potentially sending user credentials to the client.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
DIAGRAM§ 4.12 ↗
RFC 9700 · § 4.12DEFENSE
3 / 3
03
The client handles the authorization response.
The password remains outside the app.
Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
RFC 6749 § 1.7RFC 9700 § 4.12
For redirects of potentially credential-bearing requests, HTTP 307 is prohibited and 303 is recommended to avoid forwarding the POST body.
Read the updated RFC section ↗Do not forward a credential-bearing POST.
- Authorization servers MUST NOT use HTTP 307 to redirect requests that may contain user credentials.
- For HTTP redirection of such requests, servers SHOULD use 303 See Other.
- 303 unambiguously rewrites POST to GET. 302 does not guarantee the same behavior.
This is about a specific HTTP behavior, not a broken encryption channel. Even an honest client should never receive a user’s authorization-server password through a redirected request.
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