← All practicals

Sign in with a federated identity — link, then federate

Link a simulated upstream IdP identity to your account, sign in with it, then watch the Lab refuse the same assertion in anyone else’s hands — because a matching email is never proof.

1. 1

   Sign in to the Lab, then on the federation lab "sign in with ExampleCorp" as a brand-new identity.

   The Lab is the SP: it verifies ExampleCorp’s signed assertion and attaches that identity to the account you are ALREADY signed in as. Being logged in is the proof of ownership — the asserted email is only recorded as provenance, never used to pick an account.

2. 2

   Present that same identity again and watch it sign you in — a federated login, with a fresh session.

   The same (provider, subject) always resolves to the same local account: the one that linked it. Assert it under a DIFFERENT account and the Lab refuses — a subject someone else already owns can never be claimed by guessing it.

3. 3

   Now sign OUT and try again.

   Refused. A simulated IdP that will vouch for anything proves nothing, so no assertion can create an account or log anyone in on its own — that is the account-linking trap, and it is why mailbox proof here only ever comes from the Lab’s own emailed code.