An invalid redirect URI is a callback address that does not match the redirect URI registered for an OAuth 2.0 or OpenID Connect client. The authorisation server rejects the request when the URI is missing, malformed, or different from the approved value, preventing token delivery to an untrusted endpoint.
What the invalid redirect URI means in OAuth and OpenID Connect
An invalid redirect uri is not just a formatting error, it is a failed trust check at the point where an authorisation server would hand control, and tokens, back to a client. The server rejects anything that is missing, malformed, or not identical to the pre-registered callback value.
This matters because the redirect URI is part of the client’s security boundary. If the server accepted loosely matched callbacks, an attacker could steer an authorisation response toward an untrusted endpoint and capture codes or tokens meant for the legitimate application. Exact matching is therefore a core control, not a convenience rule. For a fuller walkthrough of the protocol mechanics, OAuth 2.0 and OpenID Connect Guide for Identity Teams explains where redirect URI validation sits in the flow.
How redirect URI validation prevents token leakage
Redirect URI validation blocks several abuse paths that depend on the client’s callback being too broad, too permissive, or too easy to spoof. Open redirect style weaknesses are especially dangerous when they are combined with OAuth because a seemingly harmless redirect can become a bridge from the authorisation server to an attacker-controlled destination. The practical requirement is exact, pre-registered matching rather than pattern-based trust.
That is why this error is usually handled as a security control failure, not a usability issue. A bad callback may arise from a typo, a stale configuration value, a URI scheme mismatch, a missing path, or an attempt to use a callback that was never registered. The validation logic protects both the client and the user session by ensuring the authorisation response only lands where the server already trusts it to go. The relationship between open redirects and OAuth callback abuse is covered in Open Redirect Guide.
Where invalid redirect URIs usually come from
In practice, invalid redirect URI errors often come from configuration drift between environments, mismatched callback paths across mobile and web clients, or inconsistent implementation of the exact URI that the authorisation server has on record. This is common in deployments that use multiple environments, custom schemes, reverse proxies, or native app callbacks.
It can also show up when teams assume the server will “normalize” the URL for them. OAuth and OpenID Connect redirect handling is stricter than many developers expect, because even small differences can change the trust decision. If the client registration process is sloppy, the problem may be introduced before runtime and repeated every time a login attempt is made. For teams that register clients dynamically, the registration step must still enforce redirect URI policy, as described in OAuth Dynamic Client Registration Security Guide.
Why practitioners should treat this as a security condition
Invalid redirect URI errors are often surfaced during authentication troubleshooting, but they should be read as evidence that the trust boundary is working. If the callback does not match exactly, the server is refusing to send credentials or authorisation data to an endpoint it cannot verify.
This is also where implementation quality matters. Native apps, browser-based apps, and federated login flows all have different callback constraints, and weak design choices can create user friction or tempt teams to weaken matching rules. The safer response is to keep the registration authoritative, keep the callback surface narrow, and avoid “just make it work” fixes that broaden acceptance. The broader OAuth security context, including exact redirect URI matching and related attack classes, is summarised in OAuth 2.0 Security Best Current Practice Guide.
Risk and Threat Considerations
An invalid redirect URI is usually defensive, but the surrounding problem space is high risk because redirect handling sits directly on the path to code delivery, token exchange, and session establishment. If validation is weakened, an attacker can abuse the callback trust relationship to intercept authorisation responses or redirect users into a phishing or token theft flow.
Failure mechanism: A client accepts an unsafe callback, or an implementation tolerates a near-match that should have been rejected, allowing an authorisation response to be delivered to the wrong endpoint.
Impact: Tokens, codes, or session-related data can be exposed to an untrusted party, which can lead to account takeover, consent abuse, or broader compromise of the application’s login flow.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Redirect URI validation is a core OAuth/OIDC login control. |
| Recommendation — Enforce exact redirect URI matching for every OAuth and OIDC client. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Redirect URIs protect the delivery path for authentication artefacts. |
| Recommendation — Restrict callback handling so tokens and codes only reach registered endpoints. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Exact callback allowlisting is an access-path control for authentication flows. |
| Recommendation — Review and remove overbroad redirect allowances in identity-facing applications. | ||