# open redirect in rfc6749

OAuth servers following RFC 6749 redirect to a registered redirect_uri on error responses, letting an attacker register attacker.com and use the authorize endpoint as an open redirect.

- Payout: $3,000
- Severity: medium
- Program: Internet Bug Bounty
- Credited: asanso
- Disclosed: 2015-04-06
- Write-up quality: 6/10
- Original: https://hackerone.com/reports/26962
- Library page: https://bugbountylibrary.com/r/h1%3A26962
- Tags: domain:web impact:integrity kind:bounty platform:hackerone sev:medium tech:oauth vuln:open-redirect

**Target:** OAuth authorization endpoint (/authorize)
**Root cause:** RFC 6749 §4.1.2.1 mandates redirecting error responses (e.g. invalid scope) to the client's registered redirect_uri without requiring user consent, so any registered client's redirect_uri becomes an unauthenticated open redirect.
**Steps:**
1. Register a client on victim.com OAuth provider with redirect_uri=`http://attacker.com`
2. Craft `http://victim.com/authorize?response_type=code&client_id=<id>&scope=WRONG_SCOPE&redirect_uri=http://attacker.com`
3. Trigger error via invalid scope; server redirects user-agent to attacker.com without consent screen
**How found:** Read RFC 6749 §4.1.2.1 and noticed the spec requires redirecting error responses to the registered redirect_uri without consent, then tested with an invalid scope parameter.
**Exploitation:** Attacker registers a client with attacker-controlled redirect_uri, then lures victims to the authorize URL with an invalid parameter; the server issues a 302 to attacker.com, enabling phishing/credential-harvesting under the victim's trusted domain.
**Insight:** Spec-compliant OAuth error handling is itself an open redirect: any registered client's redirect_uri is reachable pre-consent via malformed authorize requests (bad scope, etc.), so test error paths on OAuth providers rather than only the happy path.
