🪪 Sign in with ExampleCorp
Federated account linking and federated login — with the trap that catches most first attempts at "sign in with X" left in, on purpose.
ExampleCorp is a SIMULATED upstream IdP — a teaching stand-in for a real one
(Google, Okta, Entra, …). A real deployment fetches the external IdP's own published
JWKS and verifies its assertions against a key the Lab does not control. Here, because there's
no second party to run, the Lab signs the "ExampleCorp" assertion with its own key and then
verifies it against that same key — a disclosed simplification. Everything else is
standards-shaped: a real ES256 JWS with iss, aud, exp, jti, checked exactly the way a real relying party would check
it (the Lab's JWKS).
Which is exactly why this IdP can never create an account or sign you in on its own: an endpoint that will vouch for any subject and any email proves nothing about either. So it only ever speaks for the browser it just authenticated — the assertion is stamped with your own Lab session and is inert in anyone else's hands — and the only mailbox proof this app accepts stays what it always was: a code emailed to you. Sign in locally first, then link ExampleCorp.
Who are you at ExampleCorp?
This stands in for the login screen you'd see on ExampleCorp's own site. Pick a subject (their stable user id) and the email they'll assert for you.
Tip: to see the trap, sign OUT (or open a private window) and try any identity at all — even your own email. To see the other refusal, sign in as a second account and assert a subject the first one already linked.