Prevent account takeover when users link another identity

Account linking is safe only when the application proves that the same person controls both the existing account and the identity being added. A matching email address is useful discovery data, but it is not proof of account ownership. Treat linking as a privileged change, comparable to adding a recovery method.

Review date: 2026-09-06

Start from stable identity keys

For an OpenID Connect provider, store the tuple of issuer and subject as the external identity key. The OpenID Connect Core specification defines the core ID token and claims model used to identify the authenticated end user. In practice, issuer plus subject is the stable key to persist for an external login, while email is a claim about the person and not a safe account ownership key. Email can change, be recycled, differ in normalization, or arrive without the assurance your application expects.

This distinction prevents a classic collision. An attacker creates a password account with a victim’s email before the victim signs in through an enterprise provider. If the application automatically merges on email, the attacker may inherit the victim’s organization access. The inverse is also possible: a provider account created with a stale corporate address can be merged into an unrelated local account.

Use email to say, “An account may already exist; sign in to continue.” Do not reveal which login methods exist, and do not silently merge.

Require proof on both sides

A robust flow begins inside a recently authenticated session for the account that will receive the new identity. If the session is old, or the operation follows recovery, require reauthentication.

Then run a fresh authentication transaction with the identity being linked. Bind that transaction to the current session, intended provider, one-time nonce, and short expiry. On callback, validate the provider response normally and verify that the returned issuer-subject pair is not linked elsewhere. Display the exact consequence before committing: “Add Acme SSO to the account signed in as maya@example.test.”

For password linking, proof means entering the current account credential or completing a password-creation flow from an already strong session. For a passkey, require a new registration ceremony with user verification appropriate to the risk. For enterprise federation, do not assume a verified email proves control of an existing consumer identity.

Commit the link in one transaction with a uniqueness constraint on the external key. Two concurrent callbacks must produce one link, not two accounts sharing a credential.

Design unlinking and recovery together

A link is also a recovery path, so removal needs equivalent care. Before unlinking, confirm that at least one usable authentication method remains. Require recent authentication, show which method will remain, and notify the user through an independent channel. Avoid letting a session obtained through the identity being removed authorize both removal and replacement of every recovery factor without another check.

Account recovery should never auto-link an identity simply because it returns the same email. Recovery can restore access to one account; linking changes the set of credentials that can enter it. Keep those events separate in the audit log.

Record actor, target account, provider issuer, subject fingerprint, time, session assurance, and result. Avoid logging tokens or raw credentials. The OWASP Authentication Cheat Sheet emphasizes core authentication hygiene such as unique user identification, verified email use during sign-up, secure password recovery, and secure credential handling; apply the same discipline to link and unlink events. Provide a way to terminate other sessions after an unexpected link.

Test the hostile paths

Before release, exercise email recycling, case and Unicode variations, provider subject changes, two providers with the same email, concurrent callbacks, a link already owned by another account, recovery followed by linking, and unlinking the final method. Verify that failures leave both accounts unchanged.

The implementation decision is simple: linking requires an authenticated account session plus a fresh proof for the new identity, joined by a single-use transaction. Make that invariant explicit in code and database constraints, then add one end-to-end test that attempts an email-collision takeover.