SSO Misconfiguration Lab
A broken SSO connection does not look broken — it is one setting out of seven that is wrong. Review a queue of decoded SAML and OIDC Service-Provider connections and call each one: hardened, or name the defect — a signature that is never validated or only checks the envelope (XML Signature Wrapping), an open redirect in the RelayState or redirect_uri, an unsolicited IdP-initiated response with no compensations, an audience that is never bound, a replayable assertion, a weak NameID, or an unpinned signing key. You are scored on catch rate against false positives — because flagging a hardened connection (a compensated IdP-initiated portal, a PKCE public client) is its own failure. Clear the review clean.
The real job. More noise, a tighter clock.
SSO connection review
Call each SP connection: OK, or name the specific SAML / OIDC misconfiguration.
#1
wiki (SAML SP)
purpose: Internal wiki — SP-initiated SSO
#2
crm (SAML SP)
purpose: Sales CRM — production SSO
#3
helpdesk (SAML SP)
purpose: Support portal — production SSO
#4
analytics (SAML SP)
purpose: BI dashboard — production SSO
#5
timesheets (SAML SP)
purpose: Time-tracking app — production SSO
#6
expenses (SAML SP)
purpose: Expense app — production SSO
#7
billing-ui (OIDC RP)
purpose: Billing SPA — production login
#8
forum (SAML SP)
purpose: Community forum — production SSO
#9
docs (SAML SP)
purpose: Document store — production SSO
#10
payroll (SAML SP)
purpose: Payroll app — production SSO
#11
grants (SAML SP)
purpose: Research grants portal — production SSO
#12
portal-spa (OIDC RP)
purpose: Customer portal SPA — production login
#13
reports-api (OIDC RP)
purpose: Reporting web app — production login
#14
inventory (SAML SP)
purpose: Inventory app — production SSO
Catch rate vs. false positives
Review each connection, then grade. So far 0/14 called, 0/11 misconfigs caught, 0 false positive(s).
How it is scored
Catch rate = misconfigured connections given the exact right finding.
A false positive (flagging a hardened connection) takes an extra hygiene bite — a review that cries wolf is as useless as one that misses a forged-assertion gap.
Amber fields are a “read twice” cue, not the answer. Harder tiers add subtler configs and deliberate traps (a hardened IdP-initiated portal, a PKCE public client, a signature pinned to the consumed assertion).
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based SSO-misconfiguration lab: review a queue of ~20 decoded SAML and OIDC Service-Provider connections and call each one OK or name its specific defect.
- Defects seeded across the queue: signature not validated / XML Signature Wrapping, open redirect in the ACS RelayState or redirect_uri, unsolicited IdP-initiated acceptance, Audience / Recipient / Destination not bound, assertion lifetime too long or no replay protection, weak NameID / identity handling, and an IdP signing key that is not pinned.
- You are graded on catch rate weighed against false positives — flagging a correctly-hardened connection takes an extra hygiene penalty, because a review that cries wolf is as useless as one that waves through a forged-assertion gap.
- Difficulty tiers add subtler configs and deliberate traps: a hardened IdP-initiated portal, a PKCE public client with no secret, and a signature reference pinned to the consumed assertion.
- Pure SAML / OIDC hardening — nothing is parsed or sent anywhere, the connections are authored decoded summaries, and after grading every connection shows why the right verdict is right.
Frequently asked questions
What is the SSO Misconfiguration Lab?
A free, in-browser exercise where you review a queue of decoded SAML and OpenID Connect Service-Provider connections — how the signature is validated, how the post-login redirect (RelayState / redirect_uri) is checked, whether unsolicited IdP-initiated responses are accepted, whether Audience / Recipient / Destination are bound, the assertion lifetime and replay protection, how identity (NameID / sub / email) is keyed, and whether the IdP signing key is pinned — and give each one a verdict: OK, or a specific misconfiguration. You are scored on how many real defects you catch versus how many hardened connections you wrongly flag.
How is it graded?
Each connection has one correct verdict. Your catch rate is the share of misconfigured connections you identify with the exact right finding. False positives — flagging a correctly-hardened connection — carry an extra hygiene penalty, because a review that security engineers cannot trust is as useless as one that misses a signature-wrapping or open-redirect gap. A perfect run calls every connection exactly right, sound ones included.
What SSO security concepts does it cover?
Real SAML and OIDC hardening: verifying the assertion signature (not just the Response envelope) and binding the signed reference to the consumed element to block XML Signature Wrapping; exact-match allowlisting of the ACS RelayState and OIDC redirect_uri to prevent open redirects; requiring InResponseTo for SP-initiated flows and compensating hardened IdP-initiated use-cases; validating Audience / Recipient / Destination so a token minted for another SP is rejected; tight NotOnOrAfter windows plus one-time-use (assertion-ID / nonce / jti) replay protection; keying accounts on a stable, verified subject rather than a transient NameID or unverified email; and pinning the IdP signing certificate instead of trusting unauthenticated or auto-refreshed metadata.
Does it process real SSO traffic?
No. Nothing is uploaded, no SAML Response or OIDC token is parsed, and no cryptography runs. The connections are authored, realistic decoded configuration summaries bundled with the page, and the lab is fully deterministic. It runs entirely in your browser — no account, no install, nothing sent anywhere.
Who is it for?
IAM and platform engineers who configure SAML / OIDC connections, application-security reviewers who sign off SSO integrations, and anyone prepping for a security interview who wants to feel why an envelope-only signature, an unvalidated RelayState, an unsolicited assertion with no compensations or an unpinned signing key are findings — and why a hardened IdP-initiated portal or a PKCE public client is not.