Web Client

Standard authentication flows against the honest Identity Provider. Use these to get a feel for how OAuth 2.0 and OpenID Connect normally behave before working through the attack tabs.

Standard OAuth Flows Easy

Four canonical OAuth 2.0 response_type / response_mode combinations against Client 1.

Flow 1: Client 1Easy Flow 2: Client 1Easy Flow 3: Client 1Easy Flow 4: Client 1Easy

Standard OpenID Connect Flows Easy

The same four flow shapes layered with OpenID Connect — Client 1 plus one Client 2 reference.

Flow 1: Client 1Easy Flow 2: Client 1Easy Flow 3: Client 1Easy Flow 4: Client 1Easy Flow 1: Client 2Easy

Advanced OpenID Connect Flows Easy

Variants that add an extra security primitive on top of the standard authorization-code flow.

PKCE (S256)Easy PKCE (plain)Easy

Server-side attacks against the OpenID Provider. Each card groups a single attack family — click `💡 Hint?` if you're stuck.

🚩 Flag — this task hides a CTF flag. Solve the attack and the flag appears on the success page (or the endpoint named in the task).
🤖 Bot — the real flag only unlocks when the victim bot (it logs in as oemmes) walks the attack. Running it against your own account still pays a dummy flag for proof-of-technique. Paste your finished attack URL on the 🤖 Attacks using Victim-Bot tab to fire it at the bot.

Web Attacks Easy – Medium

Consent-page bypass, server-side XSS and clickjacking variants against the IdP.

Bypass Consent

💡 Hint?

Check the OIDC Core Spec §3.1.2.1 — one parameter there asks the IdP to render no UI at all. There's also a non-spec route: what does the consent page POST to when the user clicks Authorize? Both routes solve this challenge independently, and each pays out its own, different flag — so there are two distinct flags to collect here.

Bypass Consent PageEasy🚩

XSS

💡 Hint?

Once you've popped script execution on the IdP, that alone isn't the win: the flag is handed out as a cookie named flag on the consent page, so your payload has to read document.cookie and exfiltrate it to a server you control. Self-attacking only leaks a dummy value — the real flag is only set when oemmes loads your payload, so send the bot.

Server-side XSSMedium🚩🤖

Clickjacking

💡 Hint?

Each variant drops a different frame-protection mechanism. What protects an IdP from being rendered inside an attacker's iframe?

Clickjacking 1Medium Clickjacking 2Medium Clickjacking 3Medium Clickjacking 4Medium

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

💡 Hint?

How does the IdP decide whether a URL matches the allow-list? String prefix? Host equality? URL parser? And do those agree with how the browser parses the URL? Once you've leaked the code somewhere you control: a code is identity. Replay it back at the SP's /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.

Open Redirect 1Easy🚩🤖Open Redirect 2Medium🚩🤖Open Redirect 3Medium🚩🤖Open Redirect 4Hard🚩🤖

307 Redirect

💡 Hint?

What does HTTP 307 do that 302/303 doesn't (RFC 9700 §4.12)? When the IdP answers the login POST with a 307, what's in the body the browser replays to redirect_uri? Worth thinking about the redirect_uri too (might be useful when using the bot…). On variant 2 a consent page is in the way. Use the bot 🤖 to obtain the flag.

307 Redirect 1Easy 307 Redirect 2Medium🚩🤖

Replay Attacks Medium

The IdP fails to single-use authorization codes — issue once, redeem twice.

💡 Hint?

Once the SP has exchanged a code for a token, what should happen the next time the same code is presented?

Code Reuse 1Medium Code Reuse 2Medium

Client Impersonation Medium

The IdP doesn't bind the registered client_id to the credential proving ownership of it. Start each verifier once as client1 and once as client2 and compare whether the code stays bound to the client it was issued for.

Client Impersonation 1

💡 Hint?

Does the IdP validate whether a code belongs to client_id=client1 or client_id=client2? Start the flow as one client and try to redeem the code as the other.

Start as Client 1Medium Start as Client 2Medium

Client Impersonation 2

💡 Hint?

Does the IdP validate whether a code belongs to client_id=client1 or client_id=client2? Start the flow as one client and try to redeem the code as the other.

Start as Client 1Medium Start as Client 2Medium

Client-side attacks against the Service Provider / OAuth client. Each card groups one attack family — pick a task, click `💡 Hint?` if you're stuck.

🚩 Flag — this task hides a CTF flag. Solve the attack and the flag appears on the success page (or the endpoint named in the task).
🤖 Bot — the real flag only unlocks when the victim bot (it logs in as oemmes) walks the attack. Running it against your own account still pays a dummy flag for proof-of-technique. Paste your finished attack URL on the 🤖 Attacks using Victim-Bot tab to fire it at the bot.

Web Attacks Medium

Classic browser-side weaknesses layered on top of the OAuth flow.

CSRF

💡 Hint?

Could the attacker convince the user's browser to start an OAuth flow it didn't ask for? What about state and nonce — reusing the values from another session, swapping them with custom ones, or just removing them entirely?

Cross-Site Request Forgery 1Medium🚩Cross-Site Request Forgery 2Medium🚩

Redirect Attacks

💡 Hint?

Once a flow is finished, where does the response actually end up? 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?

Covert Redirect 1Easy🚩🤖Covert Redirect 2Medium🚩🤖

Replay Attacks Medium

The SP fails to detect that the same authentication artefact is being used twice.

💡 Hint?

If a code/state/nonce can be issued, what stops it from being redeemed a second time? And do two sessions share anything they shouldn't?

Replay Attack 1Medium🚩Replay Attack 2Medium🚩Replay Attack 3Medium🚩Replay Attack 4Medium🚩

ID Token Attacks Easy – Hard

The SP receives an id_token from the IdP. Each sub-section attacks a different validation step.

Wrong Recipient

⚙️ Setup

For this task, you need to receive tokens like a malicious client. You can use any website you control for this purpose, e.g., the Catcher.

🚩 Receive a flag by redeeming a token that was issued for the wrong client.

💡 Hint?

Token Recipient Confusion: does the SP check that the id_token it received was actually minted for it (the aud claim), or will it swallow a token addressed to a different client? Capture a token issued for another client, then replay it here.

In the setup box above, put a Catcher URL you control in redirect_uri and keep client_id=evilClient — a sloppily-registered client (client_secret=secret-attacker-org) the IdP lets use any redirect_uri. Click Save.
Start Wrong Recipient 1/2: the honest IdP authenticates the logged-in user and delivers an id_token with aud=evilClient to your Catcher. Save that id_token.
Click Reset (the links revert to the honest client1 flow), start Wrong Recipient 1/2 again, and in the authorization response swap the IdP-issued token for your captured one. Wrong Recipient 1 trusts aud blindly; Wrong Recipient 2 only requires aud to be a known client (evilClient passes, a random value is rejected).

Get the dummy flag first, then the real one. Run the whole capture→replay against your own login (any subject other than oemmes): you can see your Catcher and every token, so you can debug the flow until it works — a success drops a dummy flag (FLAG{oidc_trc_1_dummy}) that proves your exploit is sound. Only once that works, repeat the exact same attack while driving the 🤖 Oemmes Bot so the captured token carries sub=oemmes, which yields the real flag. With the bot you are blind — you never see its browser — so never try to debug against it.

Wrong Recipient 1Medium🚩🤖Wrong Recipient 2Hard🚩🤖

Signature Exclusion

💡 Hint?

Perhaps some insecure signing algorithms are supported? And what about different speLliNgS of the algorithm? No matter which trick lands the forgery, the flag only drops if your forged id_token carries sub=oemmes — you have to impersonate the victim, not merely defeat the signature check.

Signature Bypass 1Easy🚩Signature Bypass 2Easy🚩Signature Bypass 3Easy🚩

Key Confusion

💡 Hint?

Perhaps a confusion between symmetric and asymmetric cryptography is applicable. There was an interesting bug recently, in which the modulus was used for HMAC verification. The PEM format is just so simple and intuitive, too. Sometimes secrets are base64-encoded — make sure to check the secret base64 encoded checkbox on JWT.io. No matter which trick lands the forgery, the flag only drops if your forged id_token carries sub=oemmes — you have to impersonate the victim, not merely defeat the signature check.

Signature Bypass 4Medium🚩Signature Bypass 5Medium🚩

Insecure Key

💡 Hint?

Trust establishment is essential for JWTs. Generating your own key should be no problem for you. No matter which trick lands the forgery, the flag only drops if your forged id_token carries sub=oemmes — you have to impersonate the victim, not merely defeat the signature check.

Signature Bypass 6Hard🚩

Challenges Master

Open-ended scenarios. No step-by-step hints — combine what you learnt in the earlier sections.

Steal the tokens via XSS on the SPMaster🚩🤖Covert Redirect via AES state (🧪 demo)Master

Advanced Verification Master

Nothing here yet. Come back later.

The bot-driven attacks themselves live in the Attacks against IdPs and Attacks against Clients tabs — look for the 🤖 badge next to a task. Build the exploit there against your own account first (you'll see a dummy flag), then come back here and paste the finished attack URL below. The bot logs in as oemmes and walks the same flow on its own session; the real flag only unlocks when the bot — not your own account — is the authenticated subject. The bot enforces an allow-list of sp_verifier/idp_verifier pairs server-side, so URLs whose verifier combination isn't a designed attack are rejected.

🤖 Submit an attack URL to the bot

Build the exploit against yourself first against one of the 🤖-marked attacks in the Attacks against IdPs / Attacks against Clients tabs 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.

Same attack catalogue as the previous tabs, but executed against a malicious Identity Provider you control. Two extra families (ID Spoofing, Cross-Phase Attacks) only show up here because they need attacker-issued tokens or attacker-served metadata.

🚩 Flag — this task hides a CTF flag. Solve the attack and the flag appears on the success page (or the endpoint named in the task).
Exclusive with mIdP — only solvable from this tab, where you control the Identity Provider.

⚙️ 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 authentication flows against the honest Identity Provider. Use these to get a feel for how OAuth 2.0 and OpenID Connect normally behave before working through the attack tabs.

Standard OAuth Flows Easy

Four canonical OAuth 2.0 response_type / response_mode combinations against Client 1.

Flow 1: Client 1Easy Flow 2: Client 1Easy Flow 3: Client 1Easy Flow 4: Client 1Easy

Standard OpenID Connect Flows Easy

The same four flow shapes layered with OpenID Connect — Client 1 plus one Client 2 reference.

Flow 1: Client 1Easy Flow 2: Client 1Easy Flow 3: Client 1Easy Flow 4: Client 1Easy Flow 1: Client 2Easy

Advanced OpenID Connect Flows Easy

Variants that add an extra security primitive on top of the standard authorization-code flow.

PKCE (S256)Easy PKCE (plain)Easy

Client-side attacks against the Service Provider / OAuth client. Each card groups one attack family — pick a task, click `💡 Hint?` if you're stuck.

Web Attacks Medium

Classic browser-side weaknesses layered on top of the OAuth flow.

CSRF

💡 Hint?

Cross-Site Request Forgery 1Medium Cross-Site Request Forgery 2Medium

Redirect Attacks

💡 Hint?

Once a flow is finished, where does the response actually end up? The covert redirect after auth completes allows the attacker to leak tokens to an attacker-chosen URL.

Covert Redirect 1Easy

Replay Attacks Medium

The SP fails to detect that the same authentication artefact is being used twice.

💡 Hint?

If a code/state/nonce can be issued, what stops it from being redeemed a second time? And do two sessions share anything they shouldn't?

Replay Attack 1Medium Replay Attack 2Medium Replay Attack 3Medium Replay Attack 4Medium

ID Token Freshness Exclusive with mIdP Easy

You own the IdP — mint tokens with arbitrary time claims and see which of them the SP actually validates. The timestamps also have to form a coherent chain.

Expiration (`exp`)

💡 Hint?

Does the SP accept a long-expired token? Try an exp set to the year 1999.

Expired TokenEasy🚩

Not Before (`nbf`)

💡 Hint?

nbf means not before. Are tokens accepted that would only become valid in the year 2100?

Not-Yet-Valid TokenEasy🚩

ID Token Attacks Easy – Hard

The SP receives an id_token from the IdP. Each sub-section attacks a different validation step.

Wrong Recipient

💡 Hint?

In the setup box above, put a Catcher URL you control in redirect_uri and keep client_id=evilClient — a sloppily-registered client (client_secret=secret-attacker-org) the IdP lets use any redirect_uri. Click Save.
Start Wrong Recipient 1/2: the honest IdP authenticates the logged-in user and delivers an id_token with aud=evilClient to your Catcher. Save that id_token.
Click Reset (the links revert to the honest client1 flow), start Wrong Recipient 1/2 again, and in the authorization response swap the IdP-issued token for your captured one. Wrong Recipient 1 trusts aud blindly; Wrong Recipient 2 only requires aud to be a known client (evilClient passes, a random value is rejected).

Wrong Recipient 1Medium Wrong Recipient 2Hard

ID Spoofing Exclusive with mIdP Medium

You own the IdP — mint tokens with arbitrary claims and see which ones the SP trusts to identify you. ID Spoofing 1–2: win on sub=superadmin AND iss=https://superadmin.e-hacking.de. ID Spoofing 3–4: even when sub and iss are securely verified, there can be other claims to become a superadmin.

ID Spoofing 1Medium🚩ID Spoofing 2Medium🚩ID Spoofing 3Medium🚩ID Spoofing 4Medium🚩

Cross-Phase Attacks Exclusive with mIdP Hard

Endpoint manipulation, IdP confusion, mix-up — possible only when you control the discovery / metadata phase.

Malicious EndpointsHard IdP ConfusionHard Mix-Up AttackHard