Identity Crisis: When Email Pretends to Be a Primary Key

Assume the application already has this user:

It later adds enterprise OIDC login and uses the following callback:

The attacker now simply needs an accepted identity provider to issue a valid token whose email claim contains victim@example.com. How this happens depends on the provider and setup. It may involve a tenant administrator controlling a user attribute, an unsafe identity broker or simply a second provider that reports the same address under different identity rules.

A simplified token might look like this:

The token belongs to the attacker, as its iss and sub show. The application ignores those claims, finds user_1337 by email, copies the local account’s administrator role and creates a session for the attacker without any forgery.

As you can see here, the email_verified claim is set to false.

email_verified: true provides useful information, but not all the guarantees developers often expect.

For the fixed-provider attack described above, rejecting an absent or false email_verified claim blocks the simplest path where an ordinary user changes their email without proving control of the new mailbox. It still does not prove that the external identity was previously linked to the local account, and it offers no protection when the attacker controls the provider that sets the claim.

The claim reflects the provider’s own verification policy, which may rely on a mailbox challenge, an upstream directory, an administrator-set attribute or a custom claim mapping. Its meaning and lifecycle therefore vary by provider.

email_verified can still be required before using an email for password recovery, notifications or invitations, or accepting it under a first-time-signup policy. It just cannot perform account linking on its own.

This attack applies to any application that lets a customer register an OIDC provider, tenant, realm, user pool, environment or server.

For example, in a SaaS app, a tenant administrator may be able to create users, update email-like attributes or map custom attributes into tokens.

If the application accepts users from multiple tenants and treats the email claim as the local account key, the administrator of one tenant may be able to impersonate an account that belongs to another tenant.

The provider did exactly what its administrator requested. The relying party failed to keep tenant and subject identity separate.

Allowing customer identity providers is not itself a vulnerability. The safe design binds each issuer to one customer organisation and prevents identities from that issuer from selecting accounts outside it.

The table below shows whether an administrator can make each provider emit a victim’s email address without proving mailbox control, and which configuration makes that possible.

Here the application chooses and trusts the provider. The attacker has a normal user account but no administrative access to the provider.

The direct attack requires all of the following:

The table below shows whether an ordinary user can make a provider response contain a victim’s email address without proving mailbox control, and which settings or response-handling mistakes make that possible.

The original benchmark covered eight model configurations:

Each of these models answered the prompt 30 times. Every response contained implementations for the same ten framework stacks. We rotated the framework order between runs so that one framework was not always first or last.

The ten stacks covered JavaScript, TypeScript, Python, Java, C#, PHP, Ruby and Go.

We later added GPT-6 Astra Max, with 30 further responses covering the same ten stacks: 300 additional implementations. This extension was collected and graded after the original benchmark, so its results are reported separately from the original 2,400.

In the original benchmark, each implementation went through a framework-specific localhost application with real HTTP requests and a real database.

The tests checked:

We kept two measurements separate:

Safe binding means that the code used a provider-scoped external identity, did not let email select or silently link an existing account, and declared the required database uniqueness rule.

Correct and safe is stricter. The implementation also had to run and pass the normal login and registration flows. This distinction matters because code can express a safe binding decision while still being incomplete or broken.

Out of the original 2,400 implementations, 1,266 contained vulnerable account-binding behaviour. Another 1,092 were safe, while 42 remained indeterminate. Only 912 were both correct and safe.

That overall number hides a very large difference between models. The Astra row is a later extension and is excluded from those totals:

There is no honest yes-or-no answer that applies to every model. GPT-5.6 Sol produced vulnerable binding in 8.3% of the tested implementations. Qwen 3.8 Max did so in 91.7%. DeepSeek V4 Flash, DeepSeek V4 Pro and Claude Opus 5 were also vulnerable in roughly nine out of ten cases.

Astra had no vulnerable or indeterminate findings in its source-reviewed extension. Across the original eight-model baseline, vulnerable code was more common than safe code when the prompt did not explain the account-binding risk.

These results cover isolated model requests, not complete coding agents working inside a repository. They describe these prompts, model snapshots and provider routes, not a permanent vulnerability rate for every deployment of a model.

For the follow-up tests, we used DeepSeek V4 Flash. Each condition consisted of 30 new, stateless requests containing the same ten frameworks and the same balanced output-order schedule. That produced 300 codebases per condition. These were fresh generations, not attempts to repair the baseline answers. The model still had no repository access, tools, browsing, memory or previous messages.

The first change was deliberately vague. We appended exactly one sentence to the original user prompt:

It helped, but not much. The vulnerable rate fell from 88.0% to 70.7%, while the safe rate rose from 7.3% to 14.0%. The stricter correct-and-safe result barely increased, from 18 to 20 codebases. The secure-prompt condition also produced 46 indeterminate results, compared with 14 in the baseline, so the lower vulnerable count did not translate directly into working safe code.

The next condition supplied a focused account-binding skill as the system message and left the original user prompt unchanged. The skill gave the model the missing rule: resolve a returning identity by (issuer, subject), treat email only as a collision detector, reject both verified and unverified collisions, keep linking separate from login, and enforce ownership with a compound database constraint. It also described the eight behaviours that needed testing.

This made a much larger difference. After source review, 206 of the 300 codebases were safe and 74 were vulnerable. Another 20 remained indeterminate. The correct-and-safe count rose to 102.

V1 was still very sensitive to the framework. All 30 Express implementations were safe, but only 9 Rails implementations were safe. Spring and Laravel each produced 14 safe codebases, and the corrected ASP.NET result was 16. General instructions were better than a vague warning, but they did not transfer evenly into framework-specific code.

V2 was written around those failures. It turned the binding rule into a fixed generation contract and added concrete patterns for every framework in the benchmark. The examples showed the identity table, the complete returning-user and first-login branches, rejection of an email collision, transaction boundaries, session ordering and the database constraint. V2 also told the model to trace every branch before returning its answer.

The final result was 293 safe codebases out of 300. One was vulnerable and six were indeterminate.

Across the four DeepSeek V4 Flash conditions, each row represents 300 codebases from 30 independent model responses.

The vulnerable counts by framework were as follows. Every cell is the number of vulnerable codebases out of 30, followed by the percentage.

V2 contained examples for the original ten frameworks. We therefore tested whether the rule survived when the model had no framework example to copy.

We tested ten new responses using Rust with Axum, openidconnect and SQLx/SQLite. Rust did not appear anywhere in the skill. Each request received the same mechanically adapted implementation prompt and the exact frozen v2 skill, with one Rust implementation requested per response.

All ten were safe, executable and correct. Every implementation passed tests T1 through T8 using real localhost Axum requests and an isolated SQLite database. The lab injected an already validated OIDC principal at the callback boundary, so this test covered the generated account-binding decision rather than repeating the upstream token exchange. A source audit of all ten unchanged responses produced the same verdicts.

Ten results are enough for a useful probe, but not for a stable Rust estimate. A result of 10/10 has a Wilson 95% confidence interval of 72.2% to 100.0%. We also did not run a Rust baseline, secure-prompt condition or v1 condition. The test shows that v2 transferred to this held-out framework in these ten requests. It does not establish how the skill will behave for Rust generally or across other frameworks it has never seen.

These follow-ups tested only DeepSeek V4 Flash, so the improvement cannot be assumed for the other models. Within this model, however, the difference was large: the generic secure instruction still produced 212 vulnerable codebases, while the detailed v2 skill produced one. The remaining gap between safe binding and correct-and-safe code is why the skill should be treated as a focused account-binding control, not as proof that the rest of an application is production ready.

This repository contains the complete code, tests and v2 skill.

Keep local users and their sign-in methods in separate tables:

For OIDC, store the exact validated iss and non-empty sub. Do not lowercase, trim, normalise or rewrite either value. The database must compare them exactly and enforce the compound uniqueness constraint.

If a verifier accepts documented issuer aliases, map them to one fixed server-side namespace after validation. Keep the validated issuer or tenant when one configuration accepts independent issuers. OAuth-only providers use the trusted provider namespace plus their documented immutable account ID; an OIDC sub is unique only within its issuer and may differ between clients.

The schema uses PostgreSQL’s COLLATE "C". Other databases need an equivalent case-sensitive, normalisation-sensitive and trailing-space-sensitive comparison.

Keep three email values separate:

The collision result is the same whether email_verified is true, false or absent. A match blocks automatic registration; it never authenticates or links the existing user. Do not reserve a local email_key from an unverified provider assertion.

If a retention policy permits storing raw provider values for audit, keep them out of login, linking and recovery. Decide whether deletion should tombstone the identity binding, and never let unlinking remove the user’s final authentication or recovery method.

In a multitenant app, keep the chosen organisation, provider configuration and expected issuer in the server-side OAuth transaction. Bind that record to the browser that started the login. The callback must use this stored context; an email domain or a tenant parameter in the callback cannot grant access to an organisation.

Check that the provider is allowed to authenticate users for that organisation before looking up or creating an account. Only let a customer-controlled provider authenticate users for the organisation that registered it. The example below assumes the application already stores organisation memberships and approved provider configurations.

Use the same path for every login callback:

require_provider_allowed checks the validated issuer and provider configuration against the organisation’s approved providers. The registration helper must enforce that organisation’s provisioning policy. require_login_allowed must check the user’s membership before creating a session for the requested organisation.

Create the user and identity in one transaction using the unique constraints above. After an expected conflict, roll back and reload the exact external identity. Continue only with its owner, treat an email-key conflict as a collision and raise every other database error. Never reassign an existing binding.

Apply the usual checks for disabled, locked, deleted, cross-tenant or deprovisioned accounts before creating the session. Rotate any pre-authentication session identifier after the transaction commits.

A collision response should not identify the existing account or its sign-in methods:

Account linking adds a new credential to an existing account. Start it with a CSRF-protected POST from an authenticated user’s security settings, require recent reauthentication and choose a provider approved for the user’s organisation. Bind a random, single-use link intent to the current user, session, organisation, provider configuration, expected issuer, OAuth transaction and expiry. OAuth state protects the callback, not the action that begins linking.

Load and check the intent without consuming it. Inside the database transaction, lock its row and recheck that it still exists, has not expired and still matches all the saved bindings. Insert the identity and delete the intent in that same transaction, then commit both changes together. A missing or consumed intent must fail, even if the identity already belongs to the user. Send the notification after commit.

The identity insert still needs a uniqueness constraint. If two valid link attempts race, succeed only when the winning identity belongs to the current user. Never change an existing binding’s owner. Reject an identity linked to somebody else and reject any replay of a consumed OAuth transaction or link intent. Rolling back a database transaction does not make a redeemed OAuth code reusable.

A safe account lookup cannot compensate for a broken OAuth or OIDC flow. Use the authorization code flow with PKCE and the S256 challenge method. RFC 9700 requires PKCE for public clients and recommends it for confidential clients, including server-side web apps.

Generate a fresh, cryptographically random PKCE verifier and state for each login or linking attempt, and bind them to the browser transaction. For OIDC, send a fresh random nonce as well and check it in the returned ID token. Use a maintained library and verify that it enforces these checks:

See RFC 9700 for current OAuth security guidance and OpenID Connect Core for issuer, subject and UserInfo requirements.

If the application already finds or merges accounts by email, adding the new table is only half the fix. Do not fill it by matching provider emails to local users, even when email_verified is true. That would give the same mistake a new table.

Carry over existing (iss, sub) bindings only when they were established through authenticated account linking or another trusted provisioning process. A row created by the old email-matching flow is not enough evidence on its own. Everyone else should sign in using an existing trusted method and explicitly link their provider account. If they cannot, use the application’s established account-recovery process.

Remove lookups and automatic links based on provider email from every external login path, including fallbacks, before enabling the new flow. Review bindings created by the old flow. If you find an unauthorised link, remove it and revoke the sessions and tokens it granted.


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