Link federated identities safely

A provider subject identifier is the stable external identity key. Email can change and is not always sufficient proof that two accounts are the same person.

Store provider plus issuer-specific subject, verify the provider’s required claims, and require authenticated confirmation before linking to an existing account. Treat link and unlink as sensitive operations with audit events and recovery implications.

A useful uniqueness key is:

issuer + subject

The displayed provider name is not enough. Two issuers could use the same subject string, and one provider may operate several issuers.

Do not automatically join accounts because email text matches. Providers differ in how they verify addresses, organizations can recycle addresses, and claims can change. If the user is already signed in, ask for recent authentication before linking. If not, require proof for both accounts through a deliberate merge flow.

Prevent one external identity from linking to two local users with a database uniqueness constraint. Record who initiated the link, when it happened, and which session approved it.

Unlinking can remove the user’s only login method. Before allowing it, verify that another usable credential and recovery path remain. Notify the account through an existing trusted channel.

Design local users and external identities tables and the flow for linking a second provider. Test a colliding email and an attempt to link an already-linked subject.