Lion Cipher Lab

Defend against the OAuth 2.0 mix-up attack (RFC 9207)

• Identity & Access Management
• Advanced
• ~75 min
• Free · no account required

Why it matters

Most OAuth guidance assumes a client talks to exactly one authorization server. Real clients increasingly do not: multi-tenant SaaS, 'log in with the IdP of your choice', and B2B apps that federate to each customer's identity provider all support MANY authorization servers, sometimes ones a customer (or attacker) controls. That is the exact condition the mix-up attack needs. In a mix-up, the attacker's AS interposes in a flow the victim believes is going to a legitimate AS; the victim authenticates at the HONEST AS and a perfectly valid authorization code is minted for them -- but a naive…

What you'll learn

• the OAuth 2.0 authorization-code flow in concrete terms: authorization endpoint, redirect_uri, state, code, and the back-channel token endpoint
• why a client that supports MORE THAN ONE authorization server has an attack surface single-AS clients do not
• executing a real mix-up attack locally: an attacker AS interposes, the victim authenticates at the honest AS, and the honest code is delivered to a client that ships it to the attacker's token endpoint
• seeing account takeover end to end: the attacker redeems the leaked authorization code at the honest AS and receives the victim's access token
• the RFC 9207 fix: the AS returns an iss parameter in the authorization response and the client verifies it against the AS the flow was started with
• why per-AS state binding is necessary but NOT sufficient on its own, and why the issuer identifier is the piece that actually closes the gap
• the OAuth 2.0 Security Best Current Practice (RFC 9700) posture: mandatory iss checking, exact redirect-URI matching, and PKCE
• the judgment of when to never hand-roll OAuth, and to reach for a vetted client library with OIDC discovery instead

Steps in this lab

1. The mix-up attack, in plain terms
2. Why it works: the missing binding between response and AS
3. Set up your local, authorized, disposable lab
4. Build the honest authorization server (RFC 9207-compliant)
5. Build the attacker authorization server (the interposer)
6. Build the multi-AS client and the victim's browser
7. Run the mix-up: watch the code leak, then account takeover
8. The fix: RFC 9207 iss check plus per-AS state binding
9. The judgment: when it matters, and don't hand-roll it

Open the full interactive lab →