They protect different parts of the transaction. Exact redirect URI checks make sure the code returns to the intended callback endpoint, while state confirms that the callback belongs to the original request and is not a forged or replayed response. If either control is weak, the flow can be completed in the wrong context.
Why both redirect URI checks and state validation matter
OAuth uses two separate defenses because they solve two different problems. redirect uri checks lock the authorization response to the expected callback endpoint, while state ties that response to the specific login transaction that started it. Together, they prevent attackers from steering a valid response into the wrong place or into the wrong session.
The distinction matters operationally because a correct redirect URI alone does not prove the callback belongs to the current user or browser session. Likewise, a correct state value does not help if the authorization server is willing to send the code to an unintended redirect endpoint. RFC 6749: The OAuth 2.0 Authorization Framework defines both as core parts of the flow, and RFC 9700: Best Current Practice for OAuth 2.0 Security reflects the current security guidance that treats them as complementary protections rather than substitutes.
What each control protects in the flow
Redirect URI validation protects the destination of the authorization response. It stops an attacker from registering or substituting a callback endpoint that can receive the code or response for a different client or a different application path. In practice, this is a binding check on where the browser is allowed to return after consent.
state protects the transaction context. It is a correlation value generated by the client and returned unchanged by the authorization server, so the client can verify that the callback belongs to the same request it initiated. That makes it the main defense against cross-site request forgery style response injection and against mixing one user’s callback with another user’s login attempt.
These checks also map cleanly to implementation expectations in application security guidance. OWASP ASVS covers authentication, session handling and access-control verification in ways that align with verifying both the callback target and the request correlation value. The practical point is that OAuth correctness is not just about receiving a code, but about receiving it in the right application context.
Where flows fail when one check is missing
Weak redirect URI checks create endpoint confusion: a valid response can be delivered to a URI the client did not intend, which opens the door to code interception, token leakage, or response substitution. Weak state handling creates request confusion: an attacker can try to force a victim’s browser to complete a login or consent step that the victim never started, then attach the resulting response to a session the attacker controls.
The important failure mode is that each control covers a different trust boundary. Redirect URI validation constrains the return path, while state constrains the request identity. If either boundary is loose, the authorization code flow can be completed successfully but for the wrong party, which is why OAuth guidance now treats exact redirect matching and transaction binding as baseline defensive requirements.
That is also why the surrounding protocol documents remain useful together. OpenID Connect Core 1.0 inherits the same need for request correlation in interactive login flows, and RFC 6749: The OAuth 2.0 Authorization Framework remains the base reference for how the response should be returned and validated.
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 technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | OAuth callback validation and state handling are core OAuth/OIDC verification concerns. |
| Recommendation — Verify exact redirect handling and request correlation in every OAuth/OIDC flow. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | The flow relies on correct authentication transaction binding for user login completion. |
| AC-3 — Access Enforcement | Redirect and state checks enforce who may complete the authorization transaction. | |
| Recommendation — Bind authentication responses to the initiating user session before accepting them. Enforce strict authorization response handling at the client callback boundary. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | OAuth callback and state validation are secure authentication controls for interactive login. |
| Recommendation — Require exact callback validation and transaction correlation in authentication design. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | OAuth redirect and state checks are access-control safeguards for app sign-in flows. |
| Recommendation — Restrict callback endpoints and validate request state for every sign-in response. | ||
Practitioner Guidance
What to verify: Treat redirect URI matching as an exact allowlist check, not a partial prefix or wildcard convenience. Treat state as single-use per authorization request, with enough entropy that it cannot be guessed or reused across sessions.
Common mistake: Teams often implement one of the two controls and assume it covers the whole attack surface. It does not. Exact callback validation without transaction correlation still leaves response injection and session mix-up risk, while state alone does not stop delivery to an unintended endpoint.
What good looks like: The authorization server only redirects to pre-registered callback URIs, and the client rejects any callback whose state does not match the request it initiated. The result should be a flow that is bound both to a location and to a transaction.
Practitioner takeaway: In OAuth, redirect URI validation answers “where may the response land?” and state answers “which request does this response belong to?” You need both to keep a valid authorization response from being accepted in the wrong context.