OAuth 2.0 and OpenID Connect are the backbone of modern authentication. "Sign in with Google," enterprise SSO, API authorization — it's all OAuth under the hood. And its complexity is a goldmine for attackers.
OAuth is a framework, not a protocol. The specification leaves dozens of implementation decisions to developers — and each decision is an opportunity to introduce a vulnerability.
OAuth by the Numbers
93%
Apps Use OAuth/OIDC
35%
Audits Find OAuth Flaws
#2
Auth Attack Vector
$50K+
Top Bug Bounty Payouts
As we covered in our authentication bypass techniques article, OAuth misconfigurations are one of the top authentication vulnerability classes we encounter.
1. Redirect URI Manipulation
The most common and most dangerous OAuth vulnerability:
OAuth flow begins
User clicks "Login with Google" — app redirects to Google with a redirect_uri parameter
Attacker modifies redirect_uri
If the application allows open redirects or uses loose redirect_uri matching, the attacker crafts a malicious auth URL
User authenticates normally
User sees Google's legitimate login page and enters credentials
Authorization code sent to attacker
Google redirects to the attacker's controlled redirect_uri with the authorization code — granting the attacker access to the user's account
Common redirect_uri matching mistakes:
- Allowing any subdomain:
*.example.commatchesattacker.example.com - Path prefix matching:
/callbackmatches/callback-attacker - Missing validation entirely: any URL is accepted
- Allowing localhost in production (common leftover from development)
🛑Exact Match Only
The redirect_uri must be validated against an exact, pre-registered whitelist. No wildcards, no prefix matching, no regex. This single control prevents the majority of OAuth token theft attacks.
2. CSRF via Missing State Parameter
OAuth CSRF Attack
The attack
Attacker starts an OAuth flow with their own account, captures the authorization code, and crafts a URL that completes the flow. When the victim visits this URL, their session is linked to the attacker's OAuth account.
The impact
The attacker now has a "back door" into the victim's account via their own OAuth credentials — or the victim's account is linked to the attacker's identity, allowing account takeover.
The fix
Always use a cryptographically random state parameter. Verify it matches on the callback. This prevents an attacker from injecting their authorization code into the victim's session.
3. Token Leakage
Authorization codes and access tokens can leak through multiple channels:
Token Leakage Vectors
Browser history
When using the implicit flow, the access token appears in the URL fragment (#access_token=...). It's saved in browser history and visible to any JavaScript on the page.
Referer header
The callback page includes third-party resources (analytics, ads, CDN). The full URL — including the authorization code — is sent in the Referer header to every third-party server.
Server logs
Authorization codes in query parameters are logged by web servers, CDNs, load balancers, and monitoring tools. Anyone with log access can steal tokens.
Open redirect chains
Even with a valid redirect_uri, if the callback page has an open redirect, the token can be forwarded to an attacker-controlled domain.
⚠️The Implicit Flow Is Deprecated
The OAuth implicit flow (response_type=token) is officially deprecated. It exposes access tokens in the URL fragment, making them vulnerable to leakage, XSS, and history-based attacks. Use the authorization code flow with PKCE for all new implementations.
4. PKCE Bypasses
Proof Key for Code Exchange (PKCE) was designed to prevent authorization code interception. But implementation matters:
Missing PKCE enforcement
The authorization server supports PKCE but doesn't require it. Attacker simply omits the code_challenge parameter and the server accepts the flow without PKCE.
Method downgrade
Server supports both plain and S256 code_challenge_method. Attacker uses plain (where code_verifier equals code_challenge), making PKCE trivially bypassable.
Code reuse
Authorization code isn't invalidated after first use. Attacker intercepts the code and uses it before or after the legitimate client — both get valid tokens.
5. Scope and Permission Issues
- Scope escalation — Requesting more permissions than displayed in the consent screen
- Insufficient scope validation — API doesn't check if the token's scope covers the requested operation
- Scope persistence — Once a user grants a scope, it's automatically included in future authorizations without re-consent
- Admin scope from user token — Using a user-level OAuth token to access admin endpoints when the API only checks if a valid token exists
6. Enterprise SSO Specific Issues
Enterprise SAML and OIDC SSO introduces additional attack surface:
Common SSO Misconfigurations
- •SAML signature not validated (accept any assertion)
- •SSO bypass via direct login endpoint still active
- •No JIT provisioning controls (any SSO user gets access)
- •Session not terminated when SSO session ends
Secure SSO Implementation
- •Strict SAML signature and assertion validation
- •Direct login disabled when SSO is enforced
- •Role mapping from IdP attributes with allowlist
- •Back-channel logout and periodic session re-validation
Prevention Checklist
Redirect
Exact-match redirect_uri validation — no wildcards, no prefix matching
State + PKCE
Cryptographic state parameter + mandatory PKCE (S256 only) on every flow
Tokens
Short-lived tokens, secure storage, no tokens in URLs or logs
Validate
Verify issuer, audience, expiration, and scope on every token
How We Test OAuth
Our Web Security Auditor includes comprehensive OAuth testing:
- Flow analysis — Map all OAuth endpoints, redirect URIs, and token exchange patterns
- Redirect manipulation — Test every redirect_uri variation (subdomain, path traversal, parameter injection, open redirects)
- State and PKCE validation — Verify enforcement of CSRF protections and code verifier
- Token security — Analyze token storage, transmission, expiration, and revocation
- Scope testing — Attempt scope escalation and cross-tenant access
As we discussed in API Security: The Blind Spots Most Teams Miss, OAuth-protected APIs often have authorization gaps that go beyond the OAuth flow itself — BOLA, broken function-level auth, and insufficient scope validation on individual endpoints.
Is your OAuth implementation secure? Our Web Security Auditor tests every aspect of your authentication flow, and our expert review goes deep on complex SSO, multi-tenant OAuth, and enterprise SAML configurations. Get started.