Single sign-on has a quiet premise: when a user arrives from an identity provider, that provider has already vouched for them, so you can skip the password and just let them in. The whole point is to trust the IdP. The bug we're about to describe lived in the gap between "trust the IdP to authenticate its own users" and "trust whatever the IdP tells you about who its users are." Those are not the same sentence, and the difference was an account takeover.
Here's the setup. A tenant on our platform can configure federated connections: SAML to their corporate IdP, OIDC to another. A user signs in through one of those connections, the IdP posts back an assertion, and our server has to answer one question: which local account is this? Get that mapping wrong and you have either a stranger locked out of their own account or, far worse, a stranger walking into someone else's.
The join key was an email, and an email is just a claim
Our code answered "which account is this" the obvious way. The assertion carried an email, so we looked the user up by it: FindByEmailAsync(assertedEmail). If a matching account existed, the returning federated user was resolved onto it and signed in. Clean, simple, and exactly how a lot of SSO integrations are written.
