OAuth labs
OAuth 2.0 / SSO Attacks
What is OAuth?
OAuth 2.0 and SSO attacks exploit incorrect implementations of the authorization flow: loose redirect_uri validation, missing state parameter, authorization code leakage and insecure account linking. The typical result is account takeover of any user.
Why practice OAuth?
'Login with Google/GitHub/Facebook' is in almost every modern app, and its flow is subtle and easy to implement wrong. A loose redirect_uri or a missing state turn SSO into account takeover of the entire user base. Typical bounties: $2,000-$25,000 for an OAuth-based ATO.
What will you learn with the OAuth labs?
You'll learn to diagram the authorization code flow, manipulate redirect_uri to leak the code, detect a missing state (account-linking CSRF), abuse account linking via unverified email, and steal tokens by combining OAuth with Open Redirect or client-side XSS.
Types of OAuth we cover
- redirect_uri manipulation
Loose validation (prefix, subpath, wildcard) lets you divert the authorization code to an attacker domain.
- missing state / CSRF
Without state, the attacker fixes their code in the victim's callback and links the victim's account to their social account.
- Code/token leak
The code leaks via the Referer header, an Open Redirect or an insecure postMessage toward the attacker's domain.
- Insecure account linking
Linking by unverified email lets you claim another user's account that uses the same email.
How do you find and exploit OAuth?
A practical playbook — from recon to proof of concept.
- 1
Diagram the flow
Capture the whole OAuth dance: /authorize, the parameters (client_id, redirect_uri, state, scope) and the callback that swaps the code for the token.
GET /oauth/authorize?client_id=X&redirect_uri=https://app/cb&state=S&response_type=code - 2
Attack redirect_uri
Try redirect_uri variants (another path, subdomain, suffix, @, //) to see whether the provider accepts sending the code to a destination you control.
redirect_uri=https://app.com.evil.com/cb · redirect_uri=https://app/cb/../evil - 3
Check the state parameter
If it's missing or unvalidated, you can CSRF the callback: the victim uses your code and ends up linked/logged into your account, or you into theirs.
Remove &state= from the flow → does the callback still accept the code? - 4
Leak the code
Combine with a client Open Redirect or the Referer header so the authorization code leaves toward your domain.
redirect_uri points to an Open Redirect of the app → 302 to evil.com?code=... - 5
Abuse account linking
If the app links identities by unverified email, register with the victim's email and link their social account to yours.
Sign in with Google (email=victim@x.com unverified) → takeover
Learn the theory
Academy: OAuth & SSO
Loading labs...
View in full catalog →Frequently asked questions
What is an OAuth attack?
It's the exploitation of flaws in the OAuth 2.0 / SSO flow ('login with Google/GitHub'): loose redirect_uri validation, missing state parameter, authorization code leakage or insecure account linking. They usually end in account takeover of any user.
How is an insecure OAuth implementation exploited?
You manipulate redirect_uri to divert the authorization code to an attacker domain, exploit the lack of state to CSRF account linking, or leak the code via Referer/Open Redirect. With the stolen code or token, you access the victim's account.
How do you find OAuth flaws in bug bounty?
Capture the full flow and play with redirect_uri (paths, subdomains, suffixes, @), check whether state exists and is validated, and see whether the code leaks via Referer or a client Open Redirect. Account linking via unverified email is also a classic.
How do you prevent OAuth attacks?
Require an exact match of the registered redirect_uri (no wildcards or prefixes), use and validate the state parameter (or PKCE) on every flow, don't expose the code in URLs that can leak, and verify the email before linking identities in account linking.
Difference between an OAuth attack and a JWT Authentication Bypass?
An OAuth attack abuses the authorization flow between the app and the identity provider (redirect_uri, state, code). A JWT attack abuses how the app signs/verifies its own session tokens. Both can end in ATO, but they attack different phases of authentication.
Other related categories
- 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 in real labs
Every OAuth lab replicates a real bug bounty report that got paid. Create your free account, start with the Academy and move to the labs whenever you want.
No card · free Academy · cancel anytime