Federation Lab
Federation fails in two ways: you pick the wrong protocol, or you accept the wrong assertion. Work both. First choose OIDC or SAML 2.0 for each situation — a consumer SPA with an API, a legacy app that only speaks SAML, a device or social login, a government partner. Then triage decoded SAML assertions and OIDC ID tokens: accept the healthy ones, and flag the rest — expired, wrong audience, wrong recipient, unsigned or response-only-signed, a bad signature, a replay, or a lookalike issuer. You are scored on protocol fit and catch rate against false positives — because rejecting a valid assertion breaks real logins. Clear the queue clean.
The real job. More noise, a tighter clock.
Federation queue
Pick the protocol for each scenario, and triage each assertion as of receipt 2026-10-14 15:00 UTC: Valid, or the specific defect.
#1
Consumer web + mobile, with an API
You are building a greenfield consumer product: a React single-page web app and a native iOS/Android app. Both must sign the user in and then call your own JSON REST API with the user’s identity and scopes.
- ·Public clients (SPA + native) — no confidential secret storage
- ·Needs an access token with scopes to call your API
- ·Greenfield — you choose the protocol
#2
Onboarding a legacy on-prem app
IT must enable SSO into a 12-year-old on-prem Java application for employees. The app ships a SAML 2.0 Service Provider and nothing else; it cannot be modified. Your workforce IdP is Okta, which supports both.
- ·The application only speaks SAML 2.0
- ·Workforce SSO for employees
- ·The app cannot be changed
#3
Microservices with short-lived JWTs
A new microservices platform wants standardized login with OpenID Connect discovery, a JWKS endpoint for key rotation, and short-lived JSON Web Tokens that each service can validate statelessly.
- ·Wants /.well-known/openid-configuration discovery
- ·JWKS for automatic key rotation
- ·Stateless JWT validation at each service
#4
Buying SaaS that lists one protocol
Procurement signed a SaaS tool. Its SSO documentation lists exactly one option: “SAML 2.0 (SP-initiated).” Your corporate IdP is Microsoft Entra ID, which can do SAML or OIDC enterprise apps.
- ·Vendor supports SAML 2.0 only for SSO
- ·Enterprise workforce SSO
- ·Your IdP can do either
#5
Workforce SSO — SAML Response at the ACS
SP expects
Presented assertion
#6
Assertion that sat too long
SP expects
Presented assertion
#7
ID token minted for another app
SP expects
Presented ID token
#8
alg: none
SP expects
Presented ID token
#9
TV app / CLI with no browser
A smart-TV app and a developer CLI both need the user to sign in, but neither has a usable browser or keyboard. The user should authenticate on their phone/laptop and the device then receives tokens.
- ·Input-constrained device, no embedded browser
- ·User authenticates on a secondary device
- ·Device then needs tokens to call your API
#10
Social login for a B2C app
A consumer app wants one-tap “Sign in with Google / Apple / Microsoft account” so shoppers never create a password.
- ·Consumer identities from Google / Apple / Microsoft
- ·No enterprise directory involved
- ·One-tap social login UX
#11
Government partner federation
You must federate with a government agency partner. They publish SAML 2.0 IdP metadata, mandate signed assertions, require a specific NameID format, and will only interoperate over SAML.
- ·Partner publishes SAML 2.0 IdP metadata
- ·Signed assertions + specific NameID format mandated
- ·Fixed, long-lived partner relationship
#12
Lookalike issuer
SP expects
Presented assertion
#13
Signature that does not verify
SP expects
Presented ID token
#14
Recipient points somewhere else
SP expects
Presented assertion
Protocol fit + assertion triage
Call each item, then grade. So far 0/14 called, 0/7 protocols, 0/6 bad assertions caught, 0 false positive(s).
How it is scored
Each item is worth one point: the right protocol, or the exact right assertion verdict.
A false positive (rejecting a valid assertion) takes an extra hygiene bite — a gateway that cries wolf is as useless as one that lets bad assertions through.
Harder tiers add subtler scenarios and traps (device/social login, lookalike issuers, response-only signatures, just-lapsed tokens, and clean assertions you must accept).
Live arena
4 activeadversary staging…
What this lab is
- A free, browser-based identity-federation lab: pick OIDC vs SAML 2.0 per scenario, and triage decoded SAML assertions and OIDC ID tokens — accept the valid ones, name the defect in the bad ones.
- Protocol choices cover the real decisions: SPAs, mobile, microservices, device and social login (OIDC) vs enterprise, legacy and partner SSO that only speaks SAML.
- Assertion defects seeded across the queue: expired (NotOnOrAfter / exp passed), wrong audience, wrong recipient/redirect, unsigned (incl. response-only signing), bad signature, replayed, and wrong/lookalike issuer.
- You are graded on protocol fit and assertion catch rate weighed against false positives — rejecting a valid assertion takes an extra hygiene penalty, because a gateway that cries wolf breaks real logins.
- Every time decision is judged against a fixed receipt instant, and after grading each item shows the misconfig, the fix, and why the right verdict is right.
Frequently asked questions
What is the Federation Lab?
A free, in-browser exercise in two parts. First, you choose the right federation protocol — OIDC or SAML 2.0 — for a series of real situations (a consumer SPA with an API, a legacy on-prem app that only speaks SAML, a smart-TV device login, social sign-in, a government partner). Second, you triage decoded SAML assertions and OIDC ID tokens: compare the claims against what the service provider expects and call each one Valid, or name the specific defect. You are scored on how often you pick the right protocol and how many bad assertions you catch versus how many good ones you wrongly reject.
What assertion defects does it cover?
Expired (the NotOnOrAfter or exp has passed as of receipt), wrong audience (a token minted for another SP or client_id), wrong recipient (a SubjectConfirmationData Recipient or redirect_uri that is not your ACS), unsigned (alg: none, or only the outer SAML Response is signed while the assertion is not), bad signature (present but does not verify against the issuer’s JWKS), replayed (an assertion/token ID already consumed), and wrong issuer (a lookalike or rogue IdP, including one whose signature verifies against its own key). Valid assertions are salted in as traps.
When should I choose OIDC vs SAML?
If the application or partner only supports one protocol, use that — the relying party dictates the choice. For greenfield consumer, SPA, mobile, microservice and API work — including device-code and social login — OIDC is the right answer because it is an identity layer on OAuth 2.0 and issues both an id_token for authentication and access tokens with scopes for API authorization, with discovery and JWKS key rotation. SAML 2.0 is the right answer for enterprise and workforce SSO into apps that only speak SAML, and for metadata-driven federation with fixed or government partners. The lab makes you apply this per scenario.
Does it parse real tokens?
No. Nothing is uploaded and no XML or JWT is parsed, and there is no cryptography in the page. The assertions are authored, realistic decoded field snapshots bundled with the page, and every time decision is made against a single fixed receipt instant so the queue is deterministic and never goes stale. It runs entirely in your browser — no account, no install, nothing sent anywhere.
Who is it for?
IAM, platform and application-security engineers who integrate SSO, analysts reviewing federation configurations, and anyone prepping for a security or identity interview who wants to feel why an expired or alg:none or replayed assertion must be rejected, why a signature that verifies against the wrong IdP is still a trust failure, and why social and mobile login are OIDC while a fixed SAML-only partner is not.