I'm building a product that needs account linking across email/password and Google sign-in. What’s the cleanest way to do it?

The cleanest pattern is to treat one user account as the source of truth, and let it have multiple login identities attached to it:

• Email/password identity
• Google identity
• (optionally later: Apple, GitHub, etc.)

Recommended model

1) Separate “user” from “auth identities”

Use two concepts:

• User table: your app-level account/profile
• Identity table: one row per login method

Example:

• users
  • id
  • name
  • created_at
• auth_identities
  • id
  • user_id
  • provider (password, google)
  • provider_user_id / google_sub
  • email
  • password_hash nullable
  • created_at

A single user can have:

• one password identity
• one Google identity
• later, more identities

2) Link by verified email, but only with caution

The simplest and most common UX is:

• User signs in with Google
• If Google returns an email that matches an existing account
• And that email is verified by Google
• Then you can safely link the Google identity to the existing user

But be careful:

• Email alone is not enough unless you trust it’s verified by the provider
• Google emails are usually verified, which makes this reasonable
• If verification is absent or uncertain, require the user to log in with the existing method first

3) Best practice flow

Case A: User starts with email/password, later adds Google

1. User logs in with password
2. In account settings, clicks “Link Google”
3. You run Google OAuth
4. After Google returns, attach that Google identity to the current user

This is the safest flow.

Case B: User starts with Google, later adds password

1. User logs in with Google
2. In settings, they choose “Add password login”
3. Prompt them to set a password
4. Store password hash on the same user account, or create a password identity row linked to the same user

Case C: User logs in with Google and an account already exists with same verified email

Two options:

• Auto-link if you’re comfortable with the trust model
• Or better: show “An account already exists with this email. Please sign in with your password first to link Google.”

If you want the cleanest and least risky approach, prefer:

• sign in with existing method first
• then link additional provider from account settings

4) Avoid duplicate accounts

The biggest mistake is creating a new user each time a new provider logs in.

Instead:

• First check whether the provider identity already exists
• If yes, sign into that user
• If not, check whether it should be linked to an existing account
• If neither, create a new user

5) Use “account linking” screens

Have explicit UI for:

• “Link Google”
• “Link email/password”
• “Unlink Google”
• “Change password”

This reduces accidental merges and confusion.

6) Security rules

Good rules of thumb:

• Never auto-link based on email unless the email is verified
• If a user is already signed in, linking a provider is straightforward
• If an unauthenticated Google sign-in matches an existing account, consider requiring an additional confirmation step
• Don’t allow unlinking the last remaining login method unless another recovery method exists

7) If you’re using an auth provider

If you use something like:

• Firebase Auth
• Auth0
• Cognito
• Supabase Auth

They often already support account linking or identity merging, but the exact behavior varies. The key concept still applies:

• one user
• multiple identities
• explicit linking flow

Practical recommendation

If you want the cleanest implementation:

1. Model users separately from login identities
2. Let users sign in with any linked identity
3. Allow linking only when:
   • the user is already authenticated, or
   • the provider email is verified and you intentionally support auto-linking
4. Prefer manual linking from settings over automatic merging

If you want, I can also sketch:

• a database schema,
• the exact login/linking flow,
• or code for a specific stack like Firebase, Auth0, NextAuth, Supabase, or custom backend.