OAuth 2.0 redirect URI validation is the check an authorisation server performs to ensure the login response is sent only to a registered redirect URI. It compares the requested callback address against pre-registered values, which helps prevent code interception, token leakage and redirection to an attacker-controlled endpoint.
What Redirect URI Validation Actually Does in OAuth 2.0
Redirect URI validation is the authorization server’s callback guardrail. It ensures the browser is sent back only to a pre-registered endpoint that the client is allowed to use, rather than any arbitrary URL supplied at runtime. That matters because the redirect step is where OAuth responses can be intercepted if the destination is loose, guessed, or manipulated.
In practice, the check is simple in concept but strict in effect: the requested redirect URI must match an approved value, often with exact string comparison and careful handling of scheme, host, path and query. This is one of the controls that keeps an OAuth flow tied to the intended client application instead of an attacker-controlled receiver.
Why Exact Matching Matters for Authorization Code Flow Security
The redirect leg is one of the most sensitive parts of the OAuth 2.0 flow because it carries the authorization response back to the client. If validation is weak, an attacker can turn a legitimate login into a delivery mechanism for codes, tokens or session material. Exact matching reduces ambiguity, which is why modern OAuth guidance treats wildcard and overly permissive redirect handling as high risk.
For a broader view of the protocol itself, see RFC 6749: The OAuth 2.0 Authorization Framework. For current hardening expectations, RFC 9700: Best Current Practice for OAuth 2.0 Security is the authoritative reference for stricter redirect handling and related OAuth defenses.
Common Failure Modes and Abuse Patterns
Weak redirect URI handling is often exploited through open redirects, subdomain tricks, localhost impersonation, custom-scheme confusion or sloppy allowlists. The core problem is not only where the browser goes, but whether the authorization response follows that route safely. A small validation mistake can let a malicious endpoint receive an authorization code, or can send a user through a chain that leaks state information and trust.
That is why exact redirect URI matching is often discussed alongside code interception, consent phishing and token theft. The same design flaw can appear in browser-based apps, native apps and hybrid flows, but the details differ depending on whether the client uses a web callback, a custom URI scheme or a claimed HTTPS endpoint.
Internal guidance on these abuse paths is covered by Open Redirect Guide and Mobile Deep Link and App Link Security Guide. For protocol hardening beyond the redirect itself, OAuth 2.0 Security Best Current Practice Guide ties redirect exact matching to broader OAuth attack classes.
How Organisations Validate Exposure and Reduce Blast Radius
Exposure review starts with inventory: which clients are registered, which redirect URIs are configured, and which endpoints are still in use. That matters because stale callbacks, test domains, inherited tenants and forgotten mobile schemes can all remain valid long after the application owner thinks they are gone. Teams should also check whether the callback endpoint is internet-facing, whether the domain is still under their control, and whether the implementation accepts loose variations that were never intended.
Authoritative source material should come from the client registration record, the authorization server configuration and the relevant vendor documentation, not from assumptions made by application developers. When a redirect URI is used for native or mobile flows, the surrounding app-link or deep-link trust model becomes part of the exposure review, because the URI handler itself can become the weak point.
Helpful NHIMG references here include OAuth Dynamic Client Registration Security Guide for registration controls and OAuth Client ID Metadata Documents Guide for trust-policy and discovery patterns around client metadata.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Covers OAuth/OIDC authentication and redirect handling requirements. |
| Recommendation — Verify exact redirect URI handling and authorization flow requirements before release. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Redirect URI security helps protect authentication artifacts and authorization responses. |
| AC-4 — Information Flow Enforcement | Redirect validation enforces where authorization responses are allowed to flow. | |
| AC-17 — Remote Access | OAuth redirect handling governs remote authorization entry points and callback trust. | |
| Recommendation — Manage authentication-related secrets and response handling so intercepted OAuth artifacts are not reusable. Constrain authorization responses to approved destinations and block unregistered callbacks. Restrict remote callback endpoints to registered, controlled application locations. | ||
| CIS Controls v8 | CIS-5 — Account Management | OAuth client registration and callback governance are part of controlled account-like access paths. |
| Recommendation — Inventory and review OAuth clients and their registered callbacks on a recurring basis. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Redirect validation supports controlling which endpoints may receive authorization responses. |
| Recommendation — Define and enforce approved redirect destinations as part of access control policy. | ||
| MITRE ATT&CK | T1185 — Browser Session Hijacking | Redirect abuse can expose browser-delivered OAuth responses to interception. |
| Recommendation — Monitor for browser-based interception paths that can capture OAuth responses during redirects. | ||
Practitioner Guidance
Why practitioners should care: Redirect URI validation is one of those controls that looks administrative but directly shapes whether OAuth responses can be intercepted or redirected. If validation is too permissive, the rest of the flow can be technically correct and still end in compromise.
What to watch for: Treat wildcard callbacks, host-only matching, mix-and-match between environments and “temporary” development callbacks as security debt, not convenience. In mature deployments, the safest pattern is to register only the exact callback values the client truly needs and to review them whenever the client changes.
Practitioner takeaway: Validate the callback as a security boundary, not a routing preference. If the redirect destination is not exact, stable and owned, the OAuth response path is not trustworthy.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org