Standard OAuth Flows Easy
Four canonical OAuth 2.0 response_type / response_mode combinations against Client 1.
Standard OpenID Connect Flows Easy
The same four flow shapes layered with OpenID Connect — Client 1 plus one Client 2 reference.
Advanced OpenID Connect Flows Easy
Variants that add an extra security primitive on top of the standard authorization-code flow.
Web Attacks Easy – Hard
Consent-page bypass, server-side XSS and clickjacking variants against the IdP.
Bypass Consent
Clickjacking
Redirect Attacks Easy – Hard
Two families of bugs that let the IdP bounce the victim — or the victim's credentials — to an attacker-controlled URL.
Open Redirects
/verify endpoint to complete the flow and surface the flag on the success page. Self-attack pays a dummy flag; use the bot to obtain the real flag.
307 Redirect
redirect_uri?
Replay Attacks Medium
The IdP fails to single-use authorization codes — issue once, redeem twice.
Client Impersonation Medium
The IdP doesn't bind the registered client_id to the credential proving ownership of it.
Web Attacks Medium
Classic browser-side weaknesses (CSRF, covert redirect) layered on top of the OAuth flow.
state and nonce — reusing the values from another session, swapping them with custom ones, or just removing them entirely?
Replay Attacks Medium
The SP fails to detect that the same authentication artefact is being used twice.
ID Token Attacks Easy – Hard
The SP receives an id_token from the IdP. Each sub-section attacks a different validation step.
Wrong Recipient
aud claim names the client a token was minted for — but does the SP check that this matches itself?
The real win needs an id_token minted by the honest IdP for a different client, with the bot as the authenticated user. The IdP has a sloppily-registered client you can use: client_id=evilClient, client_secret=secret-attacker-org, with no redirect_uri match — point it at any catcher subdomain you own to capture oemmes's tokens, then replay the id_token here.
Signature Exclusion
Key Confusion
Insecure Key
Challenges Master
Open-ended scenarios. No step-by-step hints — combine what you learnt in the earlier sections.
Advanced Verification Master
Nothing here yet. Come back later.
oemmes and walks the attack on its own session;
the real flag only unlocks when the bot — not your own
account — is the authenticated subject. Self-running these
from the attacker account still pays a dummy flag for
proof-of-technique. The bot enforces an allow-list of
attack_ids server-side, so non-listed verifiers cannot be
laundered through it.
Open Redirect Easy – Hard
The IdP's broken redirect_uri validation lets you reroute the auth code to a host you control. Replay the captured code at /verify to log in. Self-attack pays a dummy flag; use the bot (as oemmes) to win the real one.
307 Redirect Medium
The bot logs in as the dedicated account whose password is the flag. Can you steal the flag?
Covert Redirect Medium
The covert redirect after auth completes allows the attacker to leak tokens to an attacker-chosen URL. Can you use this token to get the flag at the /flag endpoint?
Server-side XSS Medium
The IdP is XSS-vulnerable and exposes the flag in a cookie. The bot's session holds the real flag; self-attack pays a dummy.
Wrong Recipient (Token Recipient Confusion) Medium
The SP fails to check the aud claim. The bot lets you replay a token minted for a different client and pass it off as a valid login.
🤖 Submit an attack URL to the bot
Build the exploit against yourself first against one of the attacks above and observe the
dummy flag, then paste the attack URL here to fire it at the
bot — it logs in as oemmes and walks the same flow you did.
The real flag will appear in your captured-token endpoint. URL must
point to the honest IdP (idp.e-hacking.de); SP / catcher
URLs are rejected server-side.
⚙️ Setup: Custom IdP Configuration
The Client will discover the IdP by appending /.well-known/openid-configuration
to whatever you save below.
Need an mIdP instance? Spin up a Catcher and enable its mIdP bundle:
https://e-attacker.de:443/signup.
Standard OAuth Flows Easy
Four canonical OAuth 2.0 response_type / response_mode combinations against Client 1.
Standard OpenID Connect Flows Easy
The same four flow shapes layered with OpenID Connect — Client 1 plus one Client 2 reference.
Advanced OpenID Connect Flows Easy
Variants that add an extra security primitive on top of the standard authorization-code flow.
Web Attacks Medium
Classic browser-side weaknesses (CSRF, covert redirect) layered on top of the OAuth flow.
state and nonce — reusing the values from another session, swapping them with custom ones, or just removing them entirely?
Replay Attacks Medium
The SP fails to detect that the same authentication artefact is being used twice.
ID Token Attacks Easy – Hard
The SP receives an id_token from the IdP. Each sub-section attacks a different validation step.
Wrong Recipient
aud claim names the client a token was minted for — but does the SP check that this matches itself?
The real win needs an id_token minted by the honest IdP for a different client, with the bot as the authenticated user. The IdP has a sloppily-registered client you can use: client_id=evilClient, client_secret=secret-attacker-org, with no redirect_uri match — point it at any catcher subdomain you own to capture oemmes's tokens, then replay the id_token here.
ID Spoofing Exclusive with mIdP Medium
You own the IdP — mint tokens with arbitrary sub values and see whether the SP accepts them. Flag condition: the SP authenticates a token with sub=superadmin AND iss=https://superadmin.e-hacking.de
Cross-Phase Attacks Exclusive with mIdP Hard
Endpoint manipulation, IdP confusion, mix-up — possible only when you control the discovery / metadata phase.