Identity Crisis: When Email Pretends to Be a Primary Key

Say the application already has this user:

Later it adds enterprise OIDC login with this callback:

To take over user_1337, the attacker only needs one of the identity providers the app accepts to issue a valid token with victim@example.com in the email claim. How they get there depends on the provider. They might be a tenant administrator who can edit user attributes, they might go through a badly configured identity broker, or a second provider might report the same address under looser rules.

The token could look like this:

The iss and sub claims show that this is the attacker’s account. The callback never reads them. It finds user_1337 by email and gives the attacker a session with admin rights. Nothing was forged.

Checking email_verified is still worth doing. It blocks the easiest version of the attack, where an ordinary user changes their email at a provider without confirming the new address and the provider marks it unverified.

It doesn’t help when the attacker controls the provider, as in the token above. A tenant administrator on Auth0 or Amazon Cognito, for instance, can set email_verified: true themselves. Even when the flag is honest, it only says the provider believes this person controls the mailbox. It says nothing about whether this external identity was ever linked to the local account.

What "verified" means also depends on the provider. It can come from a mailbox challenge, an upstream directory, an attribute an administrator set, or a custom claim mapping.

So use email_verified when you decide whether to send password resets or notifications to an address, or whether to accept it at first signup. Just don’t use it to decide which account someone gets.

This applies to any multi-tenant app that lets customers bring their own identity provider, or their own tenant on a shared one: an Entra tenant, an Okta org, a Keycloak realm, a Cognito user pool and so on.

Whoever administers that tenant can usually create users, edit their email addresses and map custom attributes into tokens. If the app accepts users from several tenants and looks accounts up by email, an administrator of one tenant can potentially sign in as a user who belongs to another.

The provider is behaving as designed here. The bug is in the app, which lets an identity from one tenant select an account in another. Supporting customer identity providers is fine as long as each issuer is bound to one customer organisation and can only reach accounts inside it.

The table shows, for each provider, whether a tenant administrator can make it emit a victim’s email address without proving they control the mailbox.

Here the app trusts a provider it chose itself, such as Google or its own Okta org, and the attacker has an ordinary account with no admin rights. The attack works if two things are true:

The table shows which providers allow this, and which settings it depends on.

The main benchmark covered eight models:

Each model answered the prompt 30 times, and each answer included implementations for the same ten framework stacks in JavaScript, TypeScript, Python, Java, C#, PHP, Ruby and Go. We rotated the order of the frameworks between runs so that none of them always came first or last.

We ran each implementation as a localhost app for its framework, with real HTTP requests and a real database, and tested eight behaviours (T1 to T8):

We report two numbers. A codebase has safe binding if it keys external identities on the provider, never lets email select or silently link an existing account, and declares the database uniqueness constraint. It is correct and safe if it also runs and passes the normal login and registration tests. Code can make the right binding decision and still be broken, so we track the two separately.

We later ran GPT-6 Astra Max on the same prompt and stacks (30 responses, 300 implementations). Our test harness couldn’t plug in some of the code patterns Astra used, so we graded its implementations by reading the source against the same rubric instead of running them. Because of that, and because we collected them after the main run, Astra’s results are shown separately and left out of the totals.

Of the 2,400 implementations in the main run, 1,266 bound accounts unsafely, 1,092 were safe and 42 couldn’t be classified. Only 912 were both correct and safe.

Those totals hide very different results from model to model:

The GPT models did best. GPT-5.6 Sol bound accounts unsafely in 8.3% of implementations, and GPT-5.5 and GPT-5.6 Luna in 23%. Claude Opus 5, both DeepSeek models and Qwen 3.8 Max did it in roughly nine cases out of ten. Claude Opus 5 and DeepSeek V4 Pro happen to have identical totals, but they got there differently: Opus did best on ASP.NET (18 safe out of 30), DeepSeek V4 Pro on Next.js (22 out of 30). GPT-6 Astra Max, added later, had all 300 implementations judged safe on source review.

Keep two limits in mind. We tested single model requests, so these numbers don’t tell you how a full coding agent behaves inside a real repository. They also reflect these prompts, model snapshots and API providers at the time we ran them, and could change with any of those.

We ran the follow-up experiments on DeepSeek V4 Flash only. Each condition was 30 new requests with the same ten frameworks and the same rotation, giving 300 codebases per condition. The model started fresh every time and never saw its baseline answers.

When the test harness couldn’t reach a verdict on a codebase, two reviewers read the source independently, without knowing which condition it came from, and a third settled any disagreement. Source review could decide whether a codebase was safe or vulnerable, but only codebases that actually ran could count as correct and safe.

First we tried the vague option and added one sentence to the end of the prompt:

It barely helped. Vulnerable output dropped from 88.0% to 70.7% and safe output rose from 7.3% to 14.0%, but correct-and-safe only went from 18 codebases to 20. Most of the drop in vulnerable code went into the unclassifiable bucket, which grew from 14 to 46.

Next we left the user prompt alone and put a short account-binding skill in the system message. It told the model to look up returning users by (issuer, subject), use email only to detect collisions, reject collisions whether or not the email is verified, keep account linking separate from login, and enforce ownership with a compound database constraint. It also listed the eight behaviours we test for.

This worked much better: 206 of 300 codebases were safe, 74 were vulnerable and 20 couldn’t be classified. Correct-and-safe rose to 102.

The gains were uneven across frameworks. All 30 Express implementations were safe, but only 9 of the Rails ones were. Spring and Laravel managed 14 each, and ASP.NET 16. The model understood the rule but often didn’t carry it through into framework-specific code.

We wrote v2 to address those failures. It states the binding rule as a fixed contract and includes a worked example for every framework in the benchmark, covering the identity table, the returning-user and first-login branches, collision rejection, transaction boundaries, session ordering and the database constraint. It also tells the model to trace every branch before answering.

With v2, 293 of 300 codebases were safe, one was vulnerable and six couldn’t be classified. Correct-and-safe only reached 132, though. The model now makes the right binding decision almost every time, but more than half the codebases still fail to run or don’t pass the ordinary login and registration tests.

Each row below is 300 codebases from 30 responses.

Vulnerable codebases per framework, out of 30:

V2 has examples for all ten benchmark frameworks, so the model might simply have been copying them. To check, we asked for ten Rust implementations using Axum, openidconnect and SQLx with SQLite. Rust appears nowhere in the skill. Each request used the same prompt, adapted for Rust, with the v2 skill unchanged.

All ten were safe and correct, passing T1 to T8 against real localhost Axum requests and an isolated SQLite database. To focus on the binding logic, the test harness passed in an already-validated OIDC principal at the callback instead of running the full token exchange. A source audit of all ten responses gave the same verdicts.

Ten samples is a small probe. The Wilson 95% confidence interval for 10 out of 10 is 72.2% to 100%, and we didn’t run a Rust baseline or the other conditions for comparison. It’s a good sign, but it doesn’t tell you how v2 will do on Rust in general or on other frameworks.

All the follow-up tests used DeepSeek V4 Flash, so we can’t say the skill will help other models as much. For this model the difference was stark: 212 vulnerable codebases with the generic secure instruction, one with v2. Given the gap between safe and correct-and-safe, treat the skill as a fix for account binding specifically. It doesn’t make generated code production-ready.

The code, tests and v2 skill are all in the repository on GitLab.

Keep users and the external identities they sign in with in separate tables:

Store iss and sub exactly as they come out of token validation, and reject an empty sub. Don’t normalise either value. Subject identifiers are compared exactly, so two that differ only in case belong to two different users. The unique constraint on (issuer, subject) is what stops one identity from ending up attached to two accounts.

The schema uses PostgreSQL’s COLLATE "C" to get exact comparisons. On other databases, choose a collation that is case-sensitive and doesn’t ignore trailing spaces or Unicode normalisation differences.

Two edge cases. If your OIDC library accepts several documented aliases for the same issuer, map them to one fixed value after validation so the same user always gets the same key. If one configuration accepts several independent issuers, as an Entra multi-tenant app does, keep the specific issuer or tenant in the key. For plain OAuth providers with no ID token, such as GitHub, use a fixed provider name plus the provider’s documented immutable account ID. And never use an OIDC sub outside its issuer: it’s only unique within that issuer, and some providers give different values to different clients.

The provider’s email is still useful. Just keep three separate values for it:

A collision blocks automatic registration whatever email_verified says. It never logs the user in to the existing account and never links to it. Don’t reserve a local email_key based on an unverified address from a provider either.

If you keep raw provider values for auditing, don’t feed them back into login, linking or account recovery. Decide whether deleting an account should leave a tombstone for its identity bindings, and don’t let users unlink their last way of signing in or recovering the account.

Every login callback should follow the same path:

In a multi-tenant app, record the organisation, provider configuration and expected issuer on the server when the login starts, and tie that record to the browser that started it. The callback reads this saved context. An email domain or a tenant parameter in the callback URL should never decide which organisation the user signs in to.

require_provider_allowed checks the validated issuer against the organisation’s approved providers. A provider registered by a customer should only be able to sign people in to that customer’s organisation. require_login_allowed checks that the user belongs to the organisation and that the account isn’t disabled, locked or deprovisioned. The registration branch applies the organisation’s provisioning policy. All of this assumes you already store organisation memberships and approved provider configurations.

Create the user and the identity in a single transaction so the unique constraints apply. If two first logins race and the insert hits a conflict, roll back, reload the identity by its exact key and continue as its owner. A conflict on email_key is a collision. Any other database error should propagate. Never move an existing binding to a different user.

Rotate the session ID after the transaction commits.

When there’s a collision, don’t reveal the existing account or how it signs in. Something like this works:

Linking adds a new way to sign in to an account that already exists, so it has to start from that account. Kick it off with a CSRF-protected POST from the user’s security settings, ask them to reauthenticate if they haven’t done so recently, and only offer providers approved for their organisation.

Before redirecting to the provider, create a random, single-use link intent tied to the current user, session, organisation, provider configuration, expected issuer, OAuth transaction and an expiry time. OAuth’s state parameter protects the callback. The link intent is what proves the user actually asked to link.

Check the intent when the callback arrives, but don’t consume it yet. Inside the transaction, lock its row and check again that it exists, hasn’t expired and still matches everything it was bound to. Insert the identity and delete the intent in that same transaction. If the intent is missing or already used, fail, even if the identity already belongs to this user. Send the notification after the commit.

The unique constraint matters here too. If two link attempts race, succeed only if the identity that won belongs to the current user. Reject an identity that’s linked to someone else, and never reassign it. Reject replays of a used OAuth transaction or link intent as well. Rolling back your transaction won’t make the authorization code usable again, because the provider has already redeemed it.

None of this helps if the OAuth flow itself is broken. Use the authorization code flow with PKCE and the S256 method. RFC 9700 requires PKCE for public clients and recommends it for confidential ones, including server-side web apps.

Generate a fresh random PKCE verifier and state for every login or link attempt and tie them to the browser. For OIDC, send a fresh nonce too and check it in the ID token. Use a maintained library, and confirm that it checks:

On your side, rotate the session at login and harden the session cookie. RFC 9700 covers current OAuth security practice in detail, and OpenID Connect Core has the rules for issuer, subject and UserInfo.

If your app already matches or merges accounts by email, adding the identities table only fixes half the problem. Don’t populate it by matching provider emails to local users, even verified ones, because that reproduces the original bug.

Only carry over existing (iss, sub) bindings that were created through authenticated account linking or another provisioning process you trust. Bindings created by the old email-matching code don’t count. Everyone else signs in with a method they already have and links their provider account from settings. Users who can’t do that go through your normal account recovery.

Before you switch on the new flow, remove every email-based lookup and automatic link from your external login paths, fallbacks included. Then review the bindings the old flow created. If you find one that shouldn’t exist, delete it and revoke any sessions and tokens issued through it.

So, now you know how OIDC and nOAuth work. No more excuses for letting an email claim decide whose account gets opened.