Akande Simpa
Akande Simpa Lead Security Engineer & Cofounder, Simpa Labs CEH (Certified Ethical Hacker)

The OAuth 2.0 flow: Redirect URI validation bypasses

When a user initiates an OAuth flow, the client redirects them to the authorization server with a redirect_uri parameter. After authentication, the server redirects the user back to this URI with the authorization code. If the server does not enforce exact string matching on the redirect URI, attackers can exploit this validation gap:

// VULNERABLE redirect parameter using wildcard matching
https://auth.simpalabs.com/oauth/authorize?
  client_id=123&
  redirect_uri=https://example.com/oauth/callback&
  response_type=code

// Attacker-tampered bypass payload exploiting path traversal
https://auth.simpalabs.com/oauth/authorize?
  client_id=123&
  redirect_uri=https://example.com/oauth/callback/../../attacker-site.com/leak&
  response_type=code

The Fix: Enforce strict, exact-match string validation on the authorization server for all registered redirect URIs. Never allow wildcard (*) subdomain matching or dynamic path traversal resolution.

CSRF via missing state parameter

The state parameter is a cryptographically secure random token generated by the client and sent with the authorization request. The authorization server returns this state value in the callback. The client must verify that the returned state matches the value stored in the user's active session before performing the token exchange.

If the client fails to validate the state parameter, the flow is vulnerable to OAuth CSRF attacks: an attacker completes their own login flow, intercepts the code response, and trick the victim into visiting the callback URL with the attacker's code. This binds the victim's local browser session to the attacker's account, allowing the attacker to monitor their actions.

Auditing OpenID Connect (OIDC) ID token validation

OpenID Connect introduces ID Tokens (standard JSON Web Tokens). When the client receives the ID Token from the token endpoint, it must validate the token before trust is established. Common implementation mistakes we target during audits include:

Example finding

Wildcard redirect URI allows authorization code theft

During a penetration test of a SaaS provider, we found that the authorization server accepted any redirect URI that started with the client's domain. We crafted a link pointing to a subdomain containing a open redirect file-upload path. This allowed us to redirect the authorization callback to our server, capturing the authorization codes of logging-in users. Fix priority: critical. Remediated by enforcing strict exact-string redirect matching.

Integrating OAuth 2.0 or OIDC providers? Schedule a protocol security audit.

Book an OAuth / OIDC Audit

Frequently asked questions

Why is open redirect URI validation in OAuth 2.0 dangerous?

If the authorization server allows wildcard redirect URIs, an attacker can craft a login link containing a redirect parameter pointing to a malicious site. After the user logs in, the authorization code or access token is leaked to the attacker's server.

How does PKCE prevent authorization code interception?

Proof Key for Code Exchange (PKCE) requires the client to generate a secret verifier and send its hash (challenge) with the initial authorization request. During code exchange, the client must present the raw verifier, ensuring that an intercepted code cannot be exchanged by a third-party client.

What is the security difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 is an authorization framework designed for granting API access tokens. OpenID Connect is an identity layer built on top of OAuth 2.0 that introduces ID Tokens (signed JWTs) to securely verify the user's profile identity.

Related reading

Blog: JWT token security mistakes · API data leaks · Auth0 & Clerk audits

Services: API security testing · Secure architecture review