Adding Sign in with Google to existing accounts: key on the subject ID and choose a linking rule

Identify the person by subject, not email

Google's guide is blunt: do not use the email field as a unique identifier; use the sub field. The subject is unique across Google Accounts, is never reused, and does not change when the person changes their email address. The OpenID Connect standard says the same of any provider's sub within its issuer. So the provider-identity table should hold the provider name and the subject, with a uniqueness rule on that pair and a link to your own user.

• Store the email you receive as changeable profile data.
• A different email with the same sub is the same person.
• The same email with a different sub is a different Google account.

Why email matching is risky

The email that arrives in a token is only as trustworthy as its verification, which Google reports in email_verified. Even a verified Google address is a claim about the Google account, not proof that the person owns your app's account with that address, particularly if your own accounts never confirmed their emails. Linking on a match alone can give a stranger who registered the same address at another provider a customer's data. This is a design judgement drawn from how the identifiers work, not a statement of what any specific provider allows.

• An unverified address on either side should never link by itself.
• A company email can be reassigned to a new employee after someone leaves.
• A matching address at sign-up is a prompt to ask, not a decision.

Three rules to choose from

The user-initiated rule: a signed-in user opens settings and connects Google. This is the safest because control of the existing account is proved by being signed in. The both-verified rule: on first Google sign-in, link automatically only if Google reports the address verified and your own account's address was confirmed by your own email step, otherwise ask the user to sign in with their password first. The no-link rule: create a separate account and accept duplicates, which is simple but leaves customers with two histories. Whichever you choose, write it down and test its negative case.

• Show the user what is being linked and let them remove it.
• Have a lock-out path for someone who loses the Google account.
• Restricting sign-in to one company domain uses the hd claim from the signed token, not the request parameter.

Tests that prove the rule

For the chosen rule, write the cases first. A new Google user creates one account and a second sign-in returns to it. An existing password user is linked under the rule. A Google account with the same email that does not meet the rule gets no access to the existing account. A token carrying the same sub and a new email maps to the same account. Use synthetic tokens signed with a test key for unit tests and your own test Google accounts for the staging run.

How the paid outcome is accepted

The Google sign-in outcome is accepted when those four cases pass and a tampered sign-in callback creates no session. It is priced from £495 as an untested figure fixed after the linking rule is agreed; payment follows your sign-off. Silent linking by unverified email is declined. Other providers and company-directory single sign-on are separate scopes.