A redirect URI is the web address an OAuth server sends a user back to after authentication or consent. In technical terms, it is a pre-registered callback endpoint tied to an OAuth client, used to return authorization responses securely and to prevent code interception, open redirects, and token misuse.
How OAuth Redirect URIs Work
An OAuth redirect uri is the callback endpoint the authorization server sends the user back to after login or consent. It is not just a convenience URL, it is part of the client registration that binds the authorization response to a pre-approved destination.
That binding matters because it keeps the browser flow anchored to the intended application. When the redirect target is fixed in advance, the authorization server can reject responses that try to bounce to a different location, which helps prevent code interception and confused-deputy style abuse.
Why Redirect URIs Are a Security Control
Redirect URIs help define where the authorization server may deliver the code or token response. In practice, they are a control point for ensuring that the OAuth response returns only to an endpoint the client is allowed to use, rather than to an attacker-controlled page or a loosely matched domain.
That is why precise matching is so important. Small mistakes, such as overly broad wildcards, open redirect behaviour in the client, or accepting multiple equivalent callback forms without careful validation, can weaken the trust boundary around the authorization response.
Common Validation Mistakes
The main failure mode is treating the redirect URI as a string to be “close enough” rather than an exact security binding. If the application accepts unexpected path variations, alternate schemes, or downstream redirects after the callback, an attacker may be able to steer the user agent into exposing the authorization response.
Good implementations keep the registered callback set narrow and deterministic. The authorization server and the client should both enforce the same canonical form so the callback cannot be repurposed as a generic redirect or an indirect handoff to another destination.
Where Redirect URIs Fit in OAuth and OpenID Connect
Redirect URIs sit at the center of the browser-based authorization code flow, and they also matter in OpenID Connect sign-in flows that layer authentication on top of OAuth. The callback is where the client receives the authorization result, so any weakness there can affect both access delegation and login integrity.
For a broader view of the protocol flow, the client types, and the security mistakes that tend to cluster around callbacks, see the OAuth 2.0 and OpenID Connect Guide for Identity Teams. The formal protocol baseline is defined in RFC 6749: The OAuth 2.0 Authorization Framework, while modern security guidance is expanded in RFC 9700: Best Current Practice for OAuth 2.0 Security.
Risk and Threat Considerations
Redirect URI weaknesses can turn a normal login flow into a token theft or authorization code interception problem. If the callback is overly permissive, attacker-controlled infrastructure may receive the response, or a malicious intermediary redirect may leak the code before the legitimate client can redeem it.
Failure mechanism: The attacker abuses loose callback matching, open redirect behaviour, or a misregistered callback to divert the OAuth response away from the intended client endpoint.
Impact: The result can be account takeover, unauthorized API access, session compromise, or persistent access if refresh tokens or long-lived grants are exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Redirect URIs are a core OAuth and OIDC callback security requirement. |
| Recommendation — Validate exact redirect URI matching and reject any callback variations that are not explicitly registered. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth redirect handling protects authorization artifacts that function as authenticators or bearer grants. |
| AC-3 — Access Enforcement | The redirect URI binds access responses to an approved endpoint and enforces the intended client boundary. | |
| SC-23 — Session Authenticity | Callback validation helps preserve the authenticity of the OAuth exchange and prevent response injection. | |
| Recommendation — Protect authorization codes and tokens with strict lifecycle handling and limit exposure after callback. Enforce a narrow approved callback list and deny redirects that fall outside the registered destination. Verify the callback target and state handling so the authorization response cannot be redirected or replayed. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Misused redirect URIs can expose OAuth responses that underpin API authentication and session establishment. |
| Recommendation — Treat callback validation as part of authentication hardening and block any flow that leaks authorization responses. | ||
Practitioner Guidance
Why practitioners should care: Redirect URI handling is one of the few places where a small configuration mistake can undermine an otherwise well-implemented OAuth deployment. Treat the callback list as security-sensitive registration data, not as a convenience setting.
What to watch for: Review whether the registered callback set is exact, minimal, and consistent across environments, and whether any downstream application redirect logic could be chained after the OAuth callback. When teams need a compact reference for OAuth roles, flow selection, and callback-related mistakes, the same OAuth 2.0 and OpenID Connect Guide for Identity Teams is the best starting point.
Related resources from NHI Mgmt Group
- What breaks when redirect URI validation is too permissive in OAuth?
- Why does using OAuth-based social login require careful redirect URI and secret handling in production?
- Why do PKCE and exact redirect URI matching reduce OAuth abuse?
- Why do redirect URI checks and state validation both matter in OAuth flows?