Account linking
One person, several sign-in methods, one account. The rules that decide whether 'Continue with Google' joins an existing user or makes a twin.
See it
What it is
One human, several sign-in methods, one row in your users table. Account linking is the rule set that decides whether 'Continue with Google' attaches to the existing user who signed up with a password last year, or quietly creates a twin with an empty workspace. The data shape is a users table plus an accounts table (provider, provider_account_id, user_id) with a unique constraint on the provider pair, so identities hang off the user instead of being the user.
Two moments matter. Linking while signed in is the safe one: the user is already authenticated, they click 'connect GitHub', you attach the identity. Linking at sign-in time, when an unknown provider identity arrives with an email you already have, is the risky one. The default there should be to link nothing: send the person to sign in with the method they already have, and attach the new identity once they are authenticated. Silent linking on a matching email, even a verified one, is a policy decision you take deliberately for a short, audited list of issuers whose verification you actually trust, not a convenience you switch on for every provider.
Gotcha: auto-linking on email is how account takeover happens. Unverified email is the obvious version, where anyone who can get a provider to assert someone else's address walks straight in. Verified email is the subtle one: addresses get reassigned when people leave companies or domains change hands, and 'verified' means different things at different providers, so the claim is evidence rather than proof. Also plan for unlinking, which must refuse to remove the last usable credential, and for two accounts that already exist and now need a real merge of their data.
Ask AI for it
Add account linking: create an accounts table (user_id, provider, provider_account_id, unique on provider + provider_account_id) so one user can hold several identities. When a signed-in user connects a new provider, attach it directly. At sign-in, if the provider identity is unknown but the email matches an existing user, do not link automatically: prompt them to authenticate with their existing method, then attach the new identity to that session. Allow auto-linking only for an explicit allowlist of trusted issuers, gated on the provider's email_verified claim and local verification, and write that policy and its per-issuer justification down in code rather than leaving it implicit. Log every link and unlink to the audit trail. Add an unlink action that refuses to remove the last usable credential, and show connected accounts in settings.