secure-oauth-oidc

Build a transaction ledger tracing every artifact binding (state, nonce, PKCE, codes, tokens), then apply the RFC 9700 control catalog and attack matrix. Report findings with evidence, attack paths, severity, and negative tests proving each control fails closed.

Validate the signature with the expected issuer's keys, then check exact issuer equality, audience containing your client ID, time claims, nonce, and flow-specific hashes like at_hash. Commit the session atomically only after all checks pass, and never use an access token as proof of authentication.

RFC 9700 requires PKCE for public clients and recommends it for confidential clients. A confidential OIDC client may use nonce instead only with the specific token-endpoint validation precautions defined in RFC 9700 section 4.5.3.2.

A mix-up attack occurs when a multi-issuer client sends an honest issuer's code or credentials to an attacker-controlled endpoint. Prevent it by binding the chosen issuer to the user-agent session and validating the authorization response issuer using RFC 9207 iss or distinct per-issuer redirect URIs.

Use DPoP or mTLS to sender-constrain access tokens so stolen tokens cannot be replayed by an attacker. The resource server must validate both the token binding and the proof; a cnf claim without proof enforcement provides no protection.

RFC 9700 recommends against responses that return access tokens from the authorization endpoint because they are exposed to injection and leakage through browser history, Referer headers, and token substitution. Migrate to the authorization code flow with PKCE instead.