Why email is a risky key for single sign-on integrations

Single sign-on (SSO) streamlines access by letting users authenticate through trusted identity providers (IdPs) like corporate directories or social logins. The core assumption is that the IdP has already verified the user’s identity, so relying on their assertion seems safe. But a recent discovery exposed a dangerous gap in this trust model—one that turned a seemingly harmless email address into a backdoor for account takeovers.

Trusting the IdP is not the same as trusting its claims

When a user signs in via a federated connection—whether through SAML, OIDC, or another protocol—the IdP sends back an assertion containing user details. The critical question is how the receiving system maps this assertion to a local account. Many systems default to looking up users by email, using code like FindByEmailAsync(assertedEmail) to resolve the identity. If an account exists with that email, the user is logged in. Simple, intuitive, and dangerously flawed.

The flaw lies in treating the email address as an identity. An email is not a verifiable fact; it’s a string in an assertion, and its trustworthiness depends entirely on the connection it comes from. In a multi-tenant environment, you don’t control every IdP. An attacker who sets up their own SAML or OIDC provider can inject any email they choose—even one that matches a high-privilege account like ceo@othercorp.com. Our system would then resolve that assertion to the real CEO’s local account, granting the attacker access without a password, phishing attempt, or cryptographic failure. The assertion’s signature might be valid, but it vouched for a claim we had no business treating as an identity.

Harder validation won’t close the loophole

A common instinct is to add more validation: require email_verified, check the domain, or enforce stricter rules. But this approach misses the root issue. The attacker controls the assertion because they control the IdP. Any property you extract from the assertion—including email_verified—can be fabricated. Asking an untrusted IdP to certify an email’s validity is like asking a fox to guard the henhouse. Validation alone cannot fix a flawed trust model.

The problem isn’t with the email itself but with how it’s used. As a claim, it’s useful for convenience or linking accounts. As a primary key for resolving identities, it’s a liability. Email addresses are global (usable across providers) and forgeable (adjustable by the asserting party). A join key must be neither.

The fix: join on an unforgeable identity pair

The solution was to stop relying on email as the resolution key entirely. Instead, we shifted to joining on the pair (provider, sub), where sub is the subject identifier issued by the IdP for that specific user. This identifier is scoped to the provider, meaning an attacker’s IdP can mint any sub within its namespace, but it cannot produce the (provider, sub) pair of a legitimate user on another IdP.

Here’s how it works in practice:

• When a user signs in via a federated connection, the system looks up the local identity previously linked to that specific (provider, sub) pair.
• The email is treated as a hint for account linking, not for resolution. It’s only used if the email is verified by a trusted source—specifically, an IdP whose domain is explicitly allowed by the tenant.
• If the email isn’t verified or comes from an untrusted IdP, a new federated identity is created instead of mapping to an existing account.

This approach ensures that the join key is immune to forgery across provider boundaries. The namespace of the (provider, sub) pair acts as a moat, preventing attackers from hijacking accounts by manipulating email addresses.

A lesson in federated identity security

The key takeaway is to separate two critical questions in federated identity:

1. Did this provider authenticate this user? This is answered by verifying the signature on the assertion.
2. Who is this user in my system? This must be answered by a key the asserting party cannot forge across boundaries.

Treating every field in an assertion as attacker-controlled—unless the specific source is explicitly trusted for that claim—is essential. Email is often the first field developers reach for because it’s human-readable and seemingly unique. But it’s the wrong choice for resolving identities in federated systems. The fix isn’t a better lock; it’s recognizing that we’ve been reading the wrong line of the ID.

This vulnerability was discovered and patched during a pre-launch security review of our authentication server, before any users entrusted us with their logins. It’s a stark reminder that even systems passing every test can hand over the keys if they’re relying on the wrong field. The lesson applies broadly: federated identity must prioritize unforgeable keys over convenience, or risk becoming a backdoor for attackers.