Redirect URI Validation

Analogy categoryAnalogies

Why Exact-Match Validation Is Non-Negotiable

The redirect_uri tells the authorization server where to send the user back with the authorization code, and if the server accepts anything resembling a registered value, an attacker can register a lookalike client or exploit an open redirect on the legitimate domain to steer the code into their own hands. OAuth 2.1 mandates exact string matching between the redirect_uri sent in the authorization request and one of the URIs registered for that client, with no wildcard subdomains, no partial path matching, and no fallback to a default value when the parameter is omitted or malformed.

🏏

Cricket analogy: A stadium checking tickets against an exact seat number rather than just 'somewhere in the stand' prevents gate-crashers from wandering in; exact redirect_uri matching prevents the code from being sent anywhere near-enough.

Open Redirect Chains and Path Traversal

Even with a correctly registered domain, an authorization server that only checks the host portion of redirect_uri and ignores the path can be abused if the client's own web application has an open redirect vulnerability somewhere in that domain, for example a /logout?next= parameter that forwards to any external URL. An attacker crafts a redirect_uri pointing at that vulnerable endpoint on the legitimate domain, passes host validation, and the authorization code then gets silently forwarded off-domain to the attacker's server through the client's own open redirect bug.

🏏

Cricket analogy: A stadium checking only that you're 'somewhere inside the ground' rather than your specific gate lets you wander through a maintenance corridor to an unauthorized area; host-only validation lets an attacker wander through an open redirect the same way.

Registering and Enforcing the Allow-List

The correct defense is registering the complete, literal redirect_uri, scheme, host, port, and full path, at client onboarding time, and rejecting any authorization request whose redirect_uri is not byte-for-byte identical to one of those registered values. For native apps, this extends to validating custom URI schemes or, preferably, using claimed HTTPS redirect URIs via Android App Links or iOS Universal Links, which are much harder for a malicious app to hijack than an arbitrary custom scheme that any app can register on the device.

🏏

Cricket analogy: A ground authority pre-approving an exact, fixed list of accredited broadcasters rather than 'anyone with a camera' mirrors registering a literal, closed allow-list of redirect URIs rather than a pattern.

json

{
  "client_id": "s6BhdRkqt3",
  "redirect_uris": [
    "https://app.example.com/oauth/callback",
    "https://app.example.com/oauth/callback/mobile"
  ]
}

// Authorization server pseudocode:
// reject unless request.redirect_uri === one of client.redirect_uris exactly
// (scheme, host, port, and full path all compared, no substring or prefix match)

Never fall back to a 'default' registered redirect_uri when the request omits the parameter, and never accept a redirect_uri merely because its hostname matches; both behaviors have been exploited in real breaches to exfiltrate authorization codes.

redirect_uri must be validated with exact, literal string matching, not host-only or pattern matching.
OAuth 2.1 disallows wildcard subdomains and partial path matches during registration and validation.
Open redirects elsewhere on a client's domain can be chained with a validated host to exfiltrate codes.
Native apps should prefer claimed HTTPS redirect URIs over arbitrary custom URI schemes.
Never fall back to a default redirect_uri if the request parameter is missing or malformed.
The complete redirect_uri, scheme, host, port, and path, must be registered up front per client.