The most dangerous OAuth 2.0 security misconfigurations are: unvalidated redirect_uri parameters, missing PKCE (Proof Key for Code Exchange), absent or predictable state parameters, over-broad token scopes, and implicit-flow token leakage through browser history. These flaws account for a disproportionate share of account-takeover and authorization-bypass incidents in web applications. According to OWASP's API Security Top 10, broken authentication and broken object-level authorization consistently top the charts — and OAuth misconfigurations feed directly into both categories. Indian SaaS teams integrating Google, Microsoft, or custom OAuth providers are shipping these gaps every week.
Why OAuth 2.0 Misconfigurations Are a Serious Threat
OAuth 2.0 was designed to delegate authorization — not to authenticate users. The distinction matters enormously in practice. When teams conflate the two, or when they implement OAuth flows without reading RFC 6749 and RFC 7636, they create attack surfaces that are easy to exploit and hard to detect in black-box testing alone.
In India, the threat surface has widened substantially. The Digital Personal Data Protection (DPDP) Act 2023 places legal obligations on data fiduciaries to ensure that access to personal data is properly authorized. An OAuth misconfiguration that lets an attacker hijack an authorization code and trade it for a token granting access to user PII is not merely a security finding — it is a potential DPDP compliance breach. Organizations handling personal data should review their authorization flows as part of any DPDP compliance program.
The OAuth 2.0 Authorization Code Flow — and Where Attackers Strike
The authorization code flow is the recommended pattern for server-side applications. But every step in the flow has a potential abuse vector.
authorization request"]:::normal C --> S["State param added
PKCE code verifier generated"]:::success C --> NS["State param missing
No PKCE — DANGEROUS"]:::danger S --> AS["Authorization Server
shows consent screen"]:::normal NS --> AS AS --> CB["Redirect to callback URI
with auth code"]:::normal CB --> RV["redirect_uri validated
exactly — SAFE"]:::success CB --> RU["redirect_uri open
or partial match — LEAKED"]:::danger RU --> ATK["Attacker intercepts code
via referrer or open redirect"]:::danger ATK --> TK["Attacker exchanges code
for access token"]:::danger RV --> EX["Client exchanges code
for token — server-side"]:::normal EX --> PKV["PKCE verifier checked
code binding confirmed"]:::success EX --> NOP["No PKCE check
code replay possible"]:::danger PKV --> AT["Access token issued
with minimum scope"]:::success NOP --> OB["Overly broad token
scope granted"]:::danger AT --> API["API call with token
in Authorization header"]:::success OB --> API API --> TL["Token stored in
localStorage — EXPOSED"]:::danger API --> SC["Token in httpOnly cookie
or memory — SAFE"]:::success classDef normal fill:#1e3a5f,stroke:#3B82F6,color:#e2e8f0 classDef danger fill:#5f1e1e,stroke:#EF4444,color:#e2e8f0 classDef success fill:#1e3d2f,stroke:#10B981,color:#e2e8f0
Each red node in this flow represents an attack injection point. Let us examine each one in detail.
Misconfiguration 1 — Unvalidated or Partial redirect_uri
The redirect_uri is where the authorization server sends the authorization code after user consent. If your server performs only a partial match — say, checking that the URI starts with https://app.example.com — an attacker can register a malicious callback like https://app.example.com.attacker.io/callback and steal the code.
Some platforms are even more permissive, allowing any URI that contains the registered domain as a substring. This is a complete bypass of the redirect URI security model.
What to do:
- Register the exact, full callback URI including path and query parameters (where applicable).
- The authorization server must perform an exact string match, not a prefix or substring match.
- Reject any request where the
redirect_uriin the token exchange differs from the one used in the authorization request. - Audit every OAuth app you manage — especially those registered with Google Cloud Console, Azure AD, or any in-house identity provider.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanMisconfiguration 2 — Missing or Absent PKCE
PKCE (Proof Key for Code Exchange, RFC 7636) was originally designed for native and mobile applications that cannot securely store a client secret. It has since been recommended for all public clients and, increasingly, for confidential clients as well.
PKCE works by binding the authorization request to a specific token exchange. The client generates a random code_verifier, hashes it into a code_challenge, and sends the challenge with the authorization request. When exchanging the code for a token, the server demands the original verifier and checks the hash. Without this binding, a stolen authorization code can be exchanged by any party.
Many Indian SaaS teams implement only the client secret for server-side apps and skip PKCE entirely. This leaves code interception attacks viable in any scenario where the authorization code is exposed — via referrer headers, browser history, or network interception.
Misconfiguration 3 — Missing or Predictable State Parameter
The state parameter is a CSRF token for the OAuth flow. The client generates a random, unguessable value, sends it with the authorization request, and validates it when the authorization server redirects back with the code. If state is missing, an attacker can trick a logged-in user into authorizing a request the attacker crafted — the classic CSRF-against-OAuth attack.
Many teams either omit the state entirely, use a static value ("state=login"), or use the user's email or session ID as the state. All three patterns are exploitable.
The state value must be:
- Cryptographically random (at minimum 128 bits of entropy).
- Stored server-side or in a signed, tamper-evident cookie.
- Validated strictly on the callback — if absent or mismatched, the flow must be aborted.
Misconfiguration 4 — Token Leakage via Storage and Headers
Access tokens are bearer credentials. Whoever holds the token can act as the user. Yet many applications store tokens in localStorage, log them in server-side application logs, or expose them in Referer headers when navigating away from pages that embed the token in a URL fragment.
The OAuth 2.0 Threat Model (RFC 6819) explicitly calls out token leakage as a high-severity threat. The implicit flow, which returns access tokens directly in URL fragments, made this problem structural — which is why the implicit flow is now deprecated.
Secure token storage patterns:
- For SPAs: store tokens in memory (a JavaScript variable), never in
localStorageorsessionStorage. - Use
httpOnly,Secure,SameSite=Strictcookies for session tokens on server-rendered applications. - Never log tokens in application or access logs — use structured logging with field-level redaction.
- Rotate tokens aggressively and implement short expiry windows.
Misconfiguration 5 — Overly Broad Token Scopes
OAuth scopes define what a token can do. Teams frequently request the broadest available scope during development ("just use admin so we don't hit permission errors") and never narrow it before going to production.
A token with admin-level scopes for a Google Workspace integration, for instance, can read all Drive files, manage users, and send email on behalf of any user in the organization. If that token is compromised — through any of the attack vectors above — the blast radius is catastrophic.
OAuth Vulnerability Distribution in Real-World Audits
Based on findings patterns reported by OWASP and security researchers across web application audits:
Redirect URI issues dominate because they are often misconfigured at the identity provider registration level — a step developers frequently rush. PKCE omission is pervasive in Indian SaaS teams that integrated OAuth before PKCE became best practice.
OAuth Security Control Checklist
Use this checklist during code review and before any new OAuth integration goes to production:
| Control | Status Check | Risk if Missing |
|---|---|---|
| Exact redirect_uri match | Verify at authorization server config level | Authorization code theft |
| PKCE enabled | Check code_challenge in auth request logs | Code interception and replay |
| State parameter | Verify random generation and server-side validation | CSRF against OAuth flow |
| Implicit flow disabled | Confirm only auth code flow in use | Token leakage via URL fragment |
| Minimum scope | Audit registered scopes quarterly | Blast radius on token compromise |
| Token not in localStorage | Check frontend storage and network tab | XSS token exfiltration |
| Tokens excluded from logs | Verify log sanitization rules | Token exposure in log storage |
| Short token expiry | Check expires_in values in token responses | Long window for stolen token abuse |
| Token rotation on use | Verify refresh token rotation policy | Refresh token replay attacks |
| Audience validation | Confirm aud claim checked on resource server | Token substitution attacks |
What a Proper OAuth Security Audit Covers
A superficial scan will find open redirects but will miss PKCE bypass, state-param CSRF, or audience claim misvalidation. A thorough OAuth security audit requires whitebox access — source code review of the authorization request construction, the callback handler, and the token storage layer.
This is where VAPT tools that combine dynamic scanning with static analysis add material value. A free VAPT scan can surface redirect_uri issues and token exposure in HTTP responses; deeper misconfigurations — PKCE bypass, predictable state — require code-level review.
Bachao.AI surfaces OAuth-related findings as part of its web application security assessment, flagging redirect validation gaps, implicit flow usage, and token storage antipatterns. Dhisattva AI Pvt Ltd built this capability for Indian SaaS teams scaling OAuth integrations without dedicated security engineering resources.
India-Specific Context — Why This Matters Now
Three factors make OAuth security urgent for Indian SaaS right now:
DPDP Act obligations: Under the Digital Personal Data Protection Act 2023, data fiduciaries must implement appropriate technical safeguards. An OAuth misconfiguration enabling unauthorized access to personal data is a potential data breach with regulatory consequences.
Third-party integrations proliferating: Indian B2B SaaS is deeply integrated with Google Workspace, Microsoft 365, Zoho, and Razorpay — all via OAuth. Each integration is an attack surface.
CERT-In advisories: CERT-In's 2024 advisory on authentication weaknesses highlighted OAuth and SAML misconfigurations as recurring findings across critical sector assessments.