Module 22 · OAuth & SSO Authentication Flaws

Last updated: May 1, 2026

Why this module exists. OAuth 2.0 and OIDC are the universal authentication layer of the modern web — and the most-misunderstood spec in the industry. The protocol is fine; the implementations are catastrophic. “Sign in with Google”, “Sign in with Apple”, “Sign in with Facebook” — every one of these has had account-takeover bugs in the last 5 years.

The protocol in 30 seconds

1. User clicks “Sign in with Google” on app.example.com.
2. App.example.com redirects user to Google with parameters: client_id, redirect_uri, state, scope, response_type.
3. Google authenticates the user, asks for consent.
4. Google redirects back to redirect_uri with an authorization code + the state the app sent.
5. App.example.com exchanges the code (server-to-server) for an access token + ID token.
6. App parses the ID token to get the user identity, creates a session.

Every step has bugs in the wild.

Bug class 1: missing state validation (CSRF on login)

The state parameter is meant to bind the OAuth flow to the user’s session. Attacker initiates an OAuth flow with their own Google account, captures the resulting code, then tricks the victim into “completing” the flow with the attacker’s code. Result: victim is logged into attacker’s account on the target site. Any data the victim enters now belongs to the attacker.

Fix: app generates a random state, stores it in the user’s session, validates it matches on the callback. Many implementations skip this entirely.

Bug class 2: redirect_uri bypass

Google validates that the redirect_uri sent matches one registered for the client. But “matches” is interpreted differently:

• Path traversal — registered https://app.com/callback; attacker sends https://app.com/callback/../malicious. Some validators are loose.
• Subdomain takeover — registered https://*.app.com/callback; attacker takes over abandoned.app.com via DNS dangling, receives codes for app.com.
• Open redirect — registered https://app.com/callback?next=...; if the callback handler honours next and 302s, attacker chains to their own domain.
• Fragment vs query — registered as query, attacker sends as fragment: some validators don’t compare fragments, code arrives at attacker’s domain.

Bug class 3: implicit flow + access token leak

The implicit flow returns the access token directly in the URL fragment of the redirect. Browser history, server logs, Referer headers can all leak it. The OAuth 2.1 spec deprecates implicit flow; most apps have moved to authorization-code-with-PKCE. Some haven’t.

Bug class 4: ID token validation failures

The ID token is a JWT. Apps must verify:

• Signature, with the IdP’s published public key from jwks_uri.
• iss claim matches the IdP.
• aud claim equals your client_id.
• exp not in the past.
• nonce matches what you sent (prevents replay).

Common mistakes: skipping signature verification (using alg:none), accepting any audience, missing nonce check.

Bug class 5: account-merging via email collision

App allows both password sign-up and “Sign in with Google”. Same email can sign up both ways. Critical question: does the second sign-up auto-merge with the first? Many apps say yes — and that’s dangerous.

The attack: attacker pre-registers [email protected] with a password, then waits for victim to sign up via Google. App detects existing account, merges, attacker now has access to victim’s data. Or vice versa.

Fix: never auto-merge. Email-verify the new authentication method before linking. Microsoft’s Outlook Online had a variant of this in 2018.

Real-world cases

• Uber 2019 — multiple OAuth bugs: open redirect on the partner OAuth callback enabled token theft. Bug bounty: $10K.
• Apple “Sign in with Apple” 2020 — Bhavuk Jain found that Apple would issue a JWT for any email under attacker control. Account takeover on every site that integrated SIWA. Bounty: $100K.
• Microsoft Online 2018 — auto-merge logic let attackers take over Microsoft accounts via federated identities.

Try this yourself

# PortSwigger OAuth labs (excellent)
# https://portswigger.net/web-security/oauth

# Local OAuth lab — Hydra (open-source IdP)
docker run --rm -p 4444:4444 oryd/hydra:latest serve all --dev

# Test the flow
# 1. Create a client
hydra clients create --endpoint http://localhost:4444 \
  --id test --secret secret \
  --grant-types authorization_code,refresh_token \
  --response-types code,id_token \
  --scope openid,offline \
  --callbacks http://localhost:8080/callback

# 2. Initiate login
open "http://localhost:4444/oauth2/auth?client_id=test&response_type=code&redirect_uri=http://localhost:8080/callback&scope=openid&state=abc"

# Probe redirect_uri validation
# Try various encodings, path traversals, fragments

Defender’s checklist

• Use authorization-code-with-PKCE for all flows including SPAs. Never use implicit flow in 2026.
• Validate state and nonce. Generate random; bind to session; compare on callback.
• Strict redirect_uri matching. Exact-match; no wildcards; no path traversal.
• Verify ID token thoroughly. Signature, iss, aud, exp, nonce. Use a battle-tested library (Auth0 SDK, Microsoft Identity, Passport.js with strict config).
• Never auto-merge accounts. If a password account exists with the same email as an incoming federated login, prompt the user to confirm.
• Pin trusted IdPs. Only Google, Microsoft, etc — not arbitrary OIDC discovery URLs the user can supply.
• Audit logs for every successful federated login. The token should include the IdP, time, IP, and user-agent.

OAuth / OIDC flaws — the catalogue

India context — DigiLocker, Aadhaar e-KYC, Account Aggregator

Indian federated identity adds specifics: DigiLocker OAuth — government document vault; redirect-URI strictly matched; tokens have short lifetime. Aadhaar e-KYC — UIDAI AUA flow; mutual TLS; consent OTP captured server-side. Account Aggregator — RBI-regulated consent layer; tokens scoped to specific data categories with explicit expiry. SSO via SAML — XML-based; XXE and signature-bypass remain attack classes.

Practitioner takeawayOAuth/SSO bugs in Indian apps trigger sectoral regulator scrutiny in addition to DPDP. Audit every flow against the OWASP OAuth/OIDC checklist; map findings to RBI/SEBI/IRDAI/UIDAI requirements where applicable.

OAuth client registration — the multi-tenant pitfall

Many SaaS providers let third parties register OAuth clients self-service. The registration form is now an attack surface:

OAuth scope design and least-privilege practice

Most OAuth integrations request more scope than necessary. Anti-patterns:

Performance discipline that strengthens security

A practical performance discipline that applies regardless of the specific vulnerability class is to instrument every endpoint with three SLOs: latency at the 50th, 95th, and 99th percentiles. The 50th percentile reflects typical user experience, the 95th catches tail behaviour visible to a meaningful fraction of users, and the 99th captures the long-tail outliers that often hide bugs (timeouts on a stale dependency, locking contention under load, garbage-collection pauses on a hot endpoint). Every release should compare these percentiles against the previous baseline; regressions of more than ten percent on the 95th percentile are typically worth investigating before shipping. Modern observability stacks make this routine — Datadog APM, New Relic, Honeycomb, Grafana Tempo with OpenTelemetry instrumentation, and on the open-source side Jaeger plus Prometheus plus Grafana — but the discipline matters more than the tool. Indian product teams that have adopted this percentile-driven culture report fewer surprise outages and a smaller incident-response load over time, which compounds into a stronger security posture: the same instrumentation that catches a slow endpoint also catches an exploitation attempt that forces unusual code paths.

Observability that catches attacks alongside outages

Observability for security overlaps with observability for reliability but adds a few specific signals worth instrumenting. First, application-layer authentication and authorisation events should produce structured logs with the user identifier, the action attempted, the source IP, the User-Agent fingerprint, and the outcome. Second, every state-changing API call should log its idempotency key, the request body shape, and the resulting object identifier. Third, every external dependency call should log the destination, the response code, and the latency. Together these three categories produce a clean event stream that a SIEM can correlate to detect both functional regressions and active attacks. The cost is moderate — log storage in Elasticsearch or Splunk runs perhaps thirty to sixty rupees per gigabyte per year at typical Indian-tier prices — and the payoff is dramatic: incidents that previously took days to investigate are typically resolved in hours when the relevant evidence has been pre-indexed. Indian regulators increasingly expect this level of operational logging, particularly RBI under the Cyber Security Framework Annex 1 and SEBI under the CSCRF master circular.

DPDP and sectoral obligations a practitioner cannot ignore

Under India’s Digital Personal Data Protection Act 2023, the operational obligations on any web application that handles personal data extend beyond simple consent collection. Section 8 requires that data fiduciaries implement reasonable security safeguards — interpreted in practice as reflecting a documented information security programme, regular vulnerability assessment, and demonstrable controls aligned to a recognised standard such as ISO 27001 or NIST CSF. Section 9 imposes data principal rights including access, correction, and erasure, which means the application must be architected so that these requests can be fulfilled within the prescribed timeframes (currently expected to be on the order of thirty days). Section 8(6) imposes breach notification: when a personal-data breach occurs, the data fiduciary must notify the Data Protection Board and affected data principals within prescribed timeframes (the draft Rules suggest seventy-two hours for material breaches). For the practitioner this translates into specific engineering tasks: data inventory and lineage tracking, retention controls and automated deletion at end-of-purpose, audit-grade logging of every access to personal data, breach-detection telemetry, and a formal incident-response playbook with regulatory-notification templates. The 2024-2025 inspections by RBI and SEBI of regulated entities have already cited DPDP-overlay obligations, so the alignment is not theoretical; it shapes what auditors expect to see in the next inspection cycle.

A small threat-modelling routine before every release

A short threat-modelling exercise specific to this vulnerability class is worth running before each release. The classic STRIDE framework — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — provides a useful checklist when applied to the specific data flow at hand. Begin by drawing the data flow for the feature being changed: external actors at the edge, the trust boundaries they cross, the back-end services involved, the data stores read or written, and the third-party integrations called. For each trust boundary crossing, ask which STRIDE categories apply and what controls mitigate them. The output is a small set of testable assertions: this endpoint must not allow tenant A to read tenant B’s records, this mutation must require step-up authentication, this third-party call must validate the response signature, and so on. Convert each assertion into an automated test or a manual verification step in the release checklist. The discipline pays off in two ways: first, it catches design-level bugs before they reach code review; second, it produces an auditable record of security thinking that regulators value. Indian product teams that have institutionalised this practice report fewer security incidents and shorter mean-time-to-remediate when issues are found, which compounds into better customer trust and lower regulatory friction over time.

Further reading

• OAuth 2.0 Security BCP (RFC 8252 + draft)
• OWASP SSO Cheat Sheet
• Account Aggregator Framework (RBI)

Additional FAQs

Should I use authorisation-code or PKCE for native apps?

Authorisation-code with PKCE is now the default for all clients (web, mobile, SPA). Implicit flow is deprecated. RFC 9700 and the IETF security BCP both recommend PKCE universally.

Is SAML safe in 2026?

For SSO in enterprise environments, yes — most large libraries handle XXE and signature-bypass correctly. Do not write your own SAML implementation; use Spring Security / python3-saml / similar mature libraries.