Preventing OAuth Attacks

OAuth has a short list of controls that, applied together, close almost the entire attack surface. None of them are cryptographic heavy lifting. They are validation discipline. This page is the defensive reference for the cluster. Want to see why the weak controls fail? Practice the bypasses on a live target.

Exact-match redirect_uri allow-lists

The single highest-impact control. Register the full redirect_uri values a client may use, and on every flow require the submitted value to equal one of them exactly:

• No wildcards, no prefix, suffix, or substring matching, no "contains."
• No open redirects on allowed callback hosts, which turn an exact match into a forwarder.
• Compare the whole URL, and if you must decode, decode once fully before comparing.

This defeats every redirect_uri trick in one move.

Mandatory PKCE

Require PKCE on every public client (SPAs, mobile, anything without a confidential secret), and ideally everywhere:

• The client sends a code_challenge, and the token endpoint requires the matching code_verifier.
• This binds the code to the client instance, so an intercepted code cannot be redeemed by an attacker.
• PKCE is necessary but not sufficient: it does not cover redirect_uri validation, CSRF, or linking.

Enforce and verify state (and nonce)

Generate a high-entropy state per flow, store it in the session, and reject any callback whose state does not match:

• state stops login CSRF by binding the callback to the user's session.
• For OIDC, enforce nonce the same way to stop ID-token replay.
• Enforce both state and PKCE unless you have a specific, well-reasoned exception.

Drop implicit and hybrid

Use the authorization code flow only:

• Deprecate response_type=token (implicit), the OIDC implicit id_token token, and the hybrid code token / code id_token responses.
• Keep tokens out of the URL entirely, including response_mode=query.
• This follows the OAuth 2.0 Security Best Current Practice (RFC 9700), which says SHOULD NOT use implicit, and OAuth 2.1, which removes it.

Verify email ownership before linking

Never merge a social identity onto an existing account on a matching email claim alone:

• Require the user to prove control of the existing account (log in, or confirm a link sent to its address) before linking.
• Verify email at signup, so an attacker cannot pre-register a local account on someone else's address.
• Key accounts on iss plus sub, not on a mutable email.

Validate ID tokens and pin JWKS

On every OIDC ID token:

• Validate the signature, iss, aud, exp, and nonce.
• Pin the JWKS or fetch it only from the provider's discovery document, and reject alg:none and attacker-supplied key URLs (jku/x5u). These are the same checks as in JWT.

The layered picture

• Primary: exact redirect_uri matching, enforced state, PKCE, and full ID-token validation.
• Supporting: no implicit/hybrid, verified account linking, pinned JWKS, tokens never in URLs, short-lived single-use codes.

With the primary controls in place, OAuth's common bugs simply do not have a foothold.

For the attack side of each of these, work back through the cluster from the pillar, and keep the cheat sheet handy. Ready to prove the weak controls fall? Sign up free and try it.