Does OAuth 2.0 redirect URI validation allow wildcard matching in production?

Answer to the question

In a production environment, OAuth 2.0 redirect‑URI validation does not permit wildcard matching. The specification (RFC 6749) requires clients to register the exact, absolute URI of each redirection endpoint, and most major providers enforce this rule strictly. Only a few providers offer a very limited wildcard feature (e.g., Okta’s "*" for sub‑domains), and even then it is constrained to HTTPS endpoints and must be explicitly enabled in the client’s configuration. Using a wildcard in production is considered a security risk because it can open the door to open‑redirect and authorization‑code leakage attacks.

Why the spec demands an exact match

The intent of the redirect‑URI check is to bind the authorization response to a known, trusted endpoint that the client controls. A wildcard would break that binding by allowing the authorization server to deliver the code to any host that satisfies the pattern, potentially under an attacker’s control.

Common provider behaviours

• Google, Azure AD, Auth0, Okta – Reject any redirect URI that is not an exact match of a registered value in production. Okta allows a single "*" wildcard for sub‑domains when the client is explicitly configured to do so.
• Providers that support wildcards usually require:
  • HTTPS scheme
  • Exact path match or a provider‑defined constraint
  • Explicit enabling in the client’s registration

Recommended approach for production

1. Register one distinct redirect URI per environment (e.g., https://prod.example.com/callback, https://dev.example.com/callback).
2. Never rely on pattern matching; keep the list of URIs explicit.
3. Always include a state parameter and, if using PKCE, a code challenge.
4. Enable logging for all authorization requests so that any unexpected redirect can be detected.
5. If you must support multiple sub‑domains, consider a small set of explicit URIs or a dedicated reverse‑proxy that terminates TLS and forwards to a single registered endpoint.

How to verify your provider’s behaviour

1. Check the client registration in your provider’s admin console or via the provider’s API. Look for any wildcard characters in the redirect‑URI list.
2. Send a test authorization request with a URI that matches the wildcard but is not an exact registered value. Observe whether the provider accepts it or returns invalid_request / invalid_redirect_uri.
3. Confirm that the scheme is HTTPS and that the host component matches the pattern. Try a non‑HTTPS URI to ensure it is rejected.
4. Review the provider’s latest documentation or security advisories for changes to redirect‑URI validation rules.

Missing diagnostic detail

Which OAuth provider are you using? The exact rules for wildcard support can vary, and knowing the provider will let us give a more precise recommendation.