Redirect URI bypass, missing state, PKCE downgrade and implicit flow each carry a distinct confirmation path - probing one without the others leaves real gaps open.
OpenID Connect is the auth layer for most modern applications - and the most common misconfigurations live in the flow itself, not in the cryptographic algorithm choices. Redirect URI validation, state parameter handling, PKCE enforcement and implicit flow token placement each carry a distinct confirmation path. Checking one without the others leaves real authorization bypass gaps open.
The authorization server delivers the authorization code to whatever redirect_uri the client sends in the authorization request. If the server validates by prefix rather than exact equality, a small variation routes that code to an attacker-controlled host before the client application ever sees it. Common bypass shapes include path normalization (a registered URI of https://app.example.com/callback matched against https://app.example.com/callback/../attacker.io/x) and wildcard subdomain configurations where any subdomain of the registered domain is accepted - including one an attacker can register.
The state parameter is the CSRF token of the OAuth/OIDC authorization flow. A client that initiates the authorization request without a state value - or that accepts any state value on the callback without verifying it matches what it sent - cannot detect a cross-site request forgery where an attacker injects their own code into the victim's session. The nonce parameter provides the same replay protection for ID tokens: a nonce embedded in the authorization request must appear in the returned ID token, preventing a token issued to one session from being replayed in another. Both checks are client-side responsibilities; the authorization server can only require that the fields are present, not that the client validates them.
# Baseline: proper authorization request GET /authorize ?response_type=code &client_id=app_client_123 &redirect_uri=https://app.example.com/callback &state=xK9mLp3Qr7vNsT1w &nonce=yZ2wBd8Fj1uHcE9p # State-absent CSRF probe: omit state entirely GET /authorize ?response_type=code &client_id=app_client_123 &redirect_uri=https://app.example.com/callback # IdP proceeds; callback fires with code but no state # If the client accepts the callback, CSRF protection is absent # Nonce replay probe: reuse a nonce from a prior ID token exchange # If the IdP accepts the replayed nonce, session binding is broken
PKCE (RFC 7636) protects the authorization code flow for public clients by binding the code to the original request: the client generates a random code_verifier, hashes it to a code_challenge sent in the authorization request, and must present the verifier to exchange the code for tokens. A server that makes code_challenge optional allows any client to exchange an intercepted code without proving ownership of the original request - the PKCE guarantee is gone for any client that omits the parameter. The implicit flow (response_type=token) avoids this entirely by putting the access token directly in the URL fragment, where it is visible in browser history, referrer headers, and CDN or proxy logs. RFC 9700 prohibits implicit for this reason; the exposure surface is structural, not incidental.
Redirect URI bypass that delivers an authorization code which successfully exchanges for an access token is critical - the attacker gains a real credential for the victim's account, confirmed in the probe by the token exchange response. PKCE downgrade is high because it requires an interception position on the redirect channel; the code is not yet a token without a successful exchange, but a network attacker with access to the redirect traffic can complete that exchange. State-absent CSRF is high when the flow binds a privileged account (admin scope, OAuth delegation for account management) and medium otherwise. Implicit flow token leakage is rated by what the token can access: a read-only scope token in a referrer header is medium; an admin-scoped token in browser history is critical. Reachable findings - where the misconfiguration is confirmed present but token delivery to an attacker was not demonstrated - are rated one step below the confirmed equivalent.
| Misconfiguration | Confirmation method | Severity |
|---|---|---|
| Redirect URI prefix or wildcard bypass | Code delivered to controlled probe URI; exchanges for a valid access token | Critical |
| State parameter absent or not validated | Callback accepted with mismatched or missing state; flow completes | High (privileged scope) / Medium |
| PKCE not enforced | Code exchanges without code_verifier; token returned | High |
| Implicit flow enabled | Token appears in URL fragment; referrer header leakage confirmed | Medium - Critical (scope-dependent) |
| Nonce not validated client-side | Replayed ID token accepted; session binding absent | High |
Probes stay safe throughout: each authorization flow is initiated with a controlled test account registered with the application. The redirect URI in bypass probes points to an endpoint the engine controls - no real user token is exfiltrated and no real user is affected by the code exchange. The access token returned in a confirmed finding is masked in stored evidence. The fix is on the authorization server: enforce exact-match redirect URI comparison (not prefix or wildcard), require and validate state on every authorization response, make PKCE mandatory for all client types including confidential clients, and remove implicit flow support from the server configuration entirely rather than relying on each client to opt out.