OAuth redirect binding, state, and authorization-code handling

Mechanism

OAuth delegates access through a client, authorization server, resource server, and user. The authorization code must be bound to the intended client and redirect context, while state and PKCE protect different parts of the flow. OAuth alone does not define user authentication; OpenID Connect adds identity semantics and token validation requirements.

Practical method

Draw the exact flow and identify redirect URI, state, code, code verifier, and token endpoint. Check exact redirect matching and whether code redemption requires the expected client and PKCE verifier. Test session binding with two lab browser sessions rather than treating every token as interchangeable.

authorize(client, redirect, state, challenge) -> code
redeem(code, client, redirect, verifier) -> access token

Interpreting evidence

A useful finding identifies the binding that is absent and the unintended session or recipient that benefits. A leaked code may be unusable if redemption still requires a verifier or confidential-client authentication.

Pitfalls and limits

Open redirects can matter when allowed redirect rules incorporate them. State is not a substitute for PKCE. Identity tokens and access tokens have different audiences and purposes.