How do I add SSO without breaking existing username and password logins?

You can add SSO without breaking existing username/password logins by treating SSO as an additional authentication method, not a replacement, and by building a clean account-linking flow.

Recommended approach

1) Keep your current login path

Do not remove or change the existing username/password authentication flow at first.
Users should still be able to sign in exactly as they do today.

2) Add SSO as a new sign-in option

Add buttons like:

• “Sign in with Google”
• “Sign in with Microsoft”
• “Sign in with Okta”

This lets new users and existing users choose SSO without affecting password users.

3) Use a stable internal user ID

Your app should have one internal user record, and then attach multiple identity methods to it:

• local username/password
• Google OAuth subject ID
• Microsoft Entra ID / Okta user ID, etc.

Example model:

• users
  • id
  • email
  • name
• password_credentials
  • user_id
  • password_hash
• external_identities
  • user_id
  • provider
  • provider_user_id

This prevents one login method from overwriting another.

4) Link SSO to existing accounts carefully

When someone signs in with SSO, you need a rule for whether to:

• create a new account, or
• link them to an existing account

Best practice:

• If the SSO email matches an existing account, prompt them to verify ownership before linking, or
• require the user to log in with their existing password first and then “connect SSO” in account settings

Avoid auto-linking solely by email unless you trust your IdP and have strong controls, because email can be reused or changed.

5) Make SSO optional at the account level

For existing users, let them:

• keep password login
• add SSO as a second login method
• optionally later disable password login if your org wants that

For enterprise customers, you can even enforce SSO only for specific domains or tenants while leaving others on password auth.

6) Plan for account recovery

If you add SSO, make sure you still support:

• password reset for password users
• admin recovery or backup codes for SSO-only users
• a way to relink accounts if an IdP changes

7) Handle authorization separately from authentication

SSO answers “who are you?”
Your app still needs roles/permissions internally.

Don’t base authorization only on the IdP unless you’ve intentionally integrated group/role syncing.

---

Common migration patterns

Safe phased rollout

1. Keep username/password working
2. Add SSO as an optional login method
3. Let existing users connect their SSO accounts
4. Monitor adoption
5. Optionally make SSO required later for certain orgs

Domain-based enterprise rollout

• Users from @company.com are encouraged or required to use SSO
• Personal or legacy users can continue with password login

---

Key implementation rule

Never treat “email” as the identity by itself.
Treat the combination of:

• authentication provider
• provider user ID
• your internal user ID

as the real identity mapping.

---

Practical UX suggestions

• Show both login options on the sign-in page
• If an email/password user tries SSO with the same email, explain the account-linking step
• Add “Connect SSO” in account settings
• Clearly label which methods are enabled for the account

---

Biggest pitfalls to avoid

• Auto-creating duplicate accounts for the same person
• Auto-linking by email without verification
• Removing password login too early
• Storing SSO users and password users in separate account systems
• Using email alone as the unique identifier

If you want, I can also sketch:

1. a database schema for mixed password + SSO auth, or
2. a step-by-step account linking flow diagram.