Redirect URI Validation and Security

Redirect URI Security

The redirect_uri is one of the most security-sensitive parameters in OAuth 2.0. If an attacker can manipulate the redirect URI, they can steal authorization codes or access tokens by redirecting them to a server they control.

The Open Redirect Attack

1. The attacker finds that the authorization server allows wildcard or partial matching of redirect URIs
2. The attacker crafts a malicious authorization URL:

   /authorize?client_id=legit-app
     &redirect_uri=https://legit-app.com.evil.com/callback
     &response_type=code
   

3. If the server only checks that the redirect_uri "starts with" the registered URI, it accepts the attacker's URI
4. After user authorization, the code is sent to the attacker's domain
5. The attacker exchanges the code for an access token

Validation Rules

Rule	Security Level	Notes
Exact match	Highest	Recommended. Compare the full URI string.
Path prefix match	Medium	Dangerous if subpaths can be attacker-controlled
Domain match only	Low	Vulnerable to subdomain takeover
Wildcard / regex	Lowest	Easily bypassed. Never use.

Secure Implementation

Authorization Server:

function validateRedirectUri(clientId, requestedUri) {
  const client = getClient(clientId);
  const registeredUris = client.redirect_uris;

  // Exact string match — no wildcards, no pattern matching
  if (!registeredUris.includes(requestedUri)) {
    throw new Error("Invalid redirect_uri");
  }
}

Client Registration:

• Register the exact, complete redirect URI (including path, no fragments)
• Use HTTPS (never HTTP, except for localhost during development)
• Avoid using wildcard subdomains or path parameters

Additional Protections

1. Require redirect_uri in token request: The token endpoint should require the same redirect_uri used in the authorization request and verify they match
2. Avoid open redirectors on your domain: An open redirector on the same domain as a registered redirect_uri can be chained to bypass validation
3. Use PKCE: Even if an authorization code is stolen via a redirect attack, PKCE prevents the attacker from exchanging it without the code_verifier
4. Register separate URIs per environment: Use different redirect URIs for development, staging, and production

Localhost for Development

During development, most providers allow:

http://localhost:3000/callback
http://127.0.0.1:3000/callback

These should be removed before deploying to production. Some providers (like Google) have special handling for localhost that does not require HTTPS.