Google OAuth2如何防止重复邮箱？同名同邮箱账号登录区分咨询

Great question—this is a super common edge case when dealing with Google Workspace (formerly G Suite) accounts, especially in organizations where email addresses get reassigned. Let’s break this down clearly:

如何区分新John和原John的账号 #

The key here is never rely on the email address as the unique user identifier—Google provides a far more reliable field for this: the sub (subject) claim in the OAuth2 ID token.

• The sub is a permanent, unique string assigned to every Google account. It never changes for the lifetime of the account, even if the user changes their email address.
• When the original John had john@doe.com, their Google account had a specific sub value (e.g., 101234567890123456789). When the organization reassigns john@doe.com to a new user, that new user gets a completely different sub (e.g., 109876543210987654321).
• Your system should store the sub as the primary key for user records, not the email. So when the new John logs in, your backend will look up the sub in your database, find no match, and create a new user record—even though the email already exists in the system (linked to the old John’s sub).

Google OAuth2如何防止重复邮箱的问题 #

Google doesn’t "prevent" duplicate email addresses in the sense of blocking reassignment (since Workspace explicitly allows organizations to reuse email addresses for new employees). Instead, OAuth2 provides the sub claim to eliminate ambiguity:

• The sub is guaranteed to be unique per Google account, regardless of email overlaps. This is the official way Google intends developers to distinguish between users.
• Even if two different Google accounts (personal and Workspace, or reassigned Workspace accounts) share the same email, their sub values will always be distinct.
• When validating the ID token, always extract and verify the sub claim alongside the email. Use the sub to tie the login to a specific user in your system, not the email.

实践建议 #

• Database design: Set your user table’s primary key to the sub string (it’s a 21-character alphanumeric string, so it’s easy to store).
• Login flow: On successful OAuth2 authentication, first query your database for the sub value. If it exists, log the user into that account; if not, create a new user record with the sub and current email.
• Email updates: If an existing user changes their email (e.g., original John switches to john.smith@doe.com), update the email field in their record using their sub as the identifier—don’t create a new user.

内容的提问来源于stack exchange，提问作者Hari