Secure OAuth Redirect URI Handling

Redirect URI handling represents one of the most critical security boundaries in OAuth 2.0 implementations. When an authorization request completes, the authorization server sends the user back to a specified URI with an authorization code or access token. If an attacker can manipulate this redirect URI, they can intercept authorization codes and hijack user sessions. This article covers the security mechanisms defined in current OAuth specifications and demonstrates how to implement them correctly.

Why Redirect URI Validation Matters

The OAuth 2.0 framework defines authorization requests as a mechanism where a resource owner grants an application access to protected resources without sharing credentials. According to RFC 6749, the authorization request includes a redirect_uri parameter that tells the authorization server where to send the user after approval. This redirect URI becomes a critical security control because it determines where sensitive authorization artifacts are delivered. An attacker who controls the redirect URI can receive authorization codes or access tokens intended for the legitimate application.

Exact Matching Requirements

RFC 9700 establishes the current best practices for OAuth security and explicitly requires exact redirect URI matching. The specification states that authorization servers must require exact string matching between the registered redirect URI and the redirect_uri parameter in authorization requests. This means query parameters, fragment components, and trailing slashes must match exactly. Regex patterns, wildcards, or prefix matching are prohibited because they create attack surface that attackers exploit.

RFC 10017 reinforces this requirement for browser based applications. The specification mandates that redirect based authorization must use exact matching of registered redirect URIs to prevent authorization code interception. Browser based flows face additional risks because URLs are visible in the address bar and can be manipulated by malicious extensions, browser history, or referrer headers.

Implementing Secure Redirect Validation

When implementing OAuth redirect URI validation, applications should register exact URIs during client configuration. For Own Auth, this involves configuring OAuth options with precise redirect URIs that match the application's actual callback endpoints. The redirect URI must use HTTPS in production to prevent interception over insecure connections.

const oauthOptions: OAuthOptions = {
  google: {
    clientId: process.env.GOOGLE_CLIENT_ID,
    clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    // Register exact redirect URIs only
    redirectUri: 'https://app.example.com/auth/callback/google'
  },
  github: {
    clientId: process.env.GITHUB_CLIENT_ID,
    clientSecret: process.env.GITHUB_CLIENT_SECRET,
    redirectUri: 'https://app.example.com/auth/callback/github'
  }
};

const auth = createOwnAuth({
  oauth: oauthOptions
});

CSRF Protection Mechanisms

Beyond redirect URI validation, RFC 9700 requires CSRF protection for authorization requests. A CSRF attack on OAuth flows tricks a user into initiating an authorization request with the attacker's own authorization server state. When the user completes authentication, the authorization code goes to the attacker's redirect URI instead of the legitimate application. The state parameter provides defense against this attack by binding the authorization request to the application's session.

Applications must generate a cryptographically random state value, store it in the user's session, and verify it matches when the authorization server redirects back. This state parameter should be unpredictable and unique per authorization request to prevent attackers from guessing valid values.

Defending Against Mix Up Attacks

Mix up attacks represent a more sophisticated threat where an attacker intercepts the authorization flow by registering a malicious client with the authorization server. When a user authenticates with the attacker's client, the authorization server redirects to the legitimate application's redirect URI but includes the attacker's authorization code. The application then exchanges this code for tokens, inadvertently granting the attacker access to the user's account.

RFC 9700 specifies that applications must validate the issuer of authorization codes during token exchange. This involves checking that the authorization server that issued the code matches the server the application initiated the request with. Additionally, binding authorization codes to a specific client identifier prevents codes from being used by different clients.

Authorization Code Binding and Validation

Authorization codes must be bound to specific client applications and redirect URIs. When the authorization server issues a code, it associates the code with the client_id and redirect_uri from the original authorization request. During token exchange, the authorization server validates that the same redirect_uri is used, preventing attackers from redirecting codes to different URIs.

Applications should also implement code challenge validation for public clients using PKCE (Proof Key for Code Exchange). PKCE extends the authorization code flow with a cryptographically random code verifier and its SHA-256 hash (the code challenge). The authorization server stores the code challenge and verifies it matches the code verifier in the token request, ensuring the same client that initiated the flow completes it.

Common Implementation Mistakes

Several common mistakes weaken OAuth redirect URI security. Using HTTP redirect URIs in production exposes authorization codes to network attackers. Allowing dynamic redirect URIs based on user input enables attackers to register malicious URIs. Failing to validate redirect URIs on the authorization server allows arbitrary redirects. Using predictable or short state parameters enables CSRF prediction attacks.

• Never allow redirect URIs to be dynamically specified by users
• Always use HTTPS for production redirect URIs
• Generate state parameters with cryptographically secure random generators
• Validate redirect URIs exactly as registered without normalization tricks
• Implement PKCE for all OAuth flows including confidential clients

Summary and Security Checklist

Secure OAuth redirect URI handling requires defense in depth across multiple specification layers. Exact redirect URI matching prevents interception attacks. CSRF protection via state parameters prevents cross site request forgery. Authorization code binding prevents mix up attacks. PKCE adds additional assurance for public clients. Following RFC 9700 best practices ensures your implementation aligns with current security standards.

The OAuth security best current practice requires exact redirect URI matching, CSRF protection, and defenses against code injection and mix up attacks.