How do I add SSO to my SaaS app without breaking existing password logins?

The safest way is to add SSO as an additional login method, not a replacement, and to make identity linking explicit and reversible. A good implementation usually looks like this:

1) Keep local password auth working

Don’t change the current username/password flow at first. Introduce SSO as:

• a new “Sign in with SSO” option
• optionally domain-based routing later (acme.com users go to Acme SSO)

This avoids breaking existing users and gives you time to migrate gradually.

2) Add an identity model that supports multiple auth methods

Instead of “one user = one credential,” model:

• User
• AuthIdentity (or ExternalLogin)
  • provider: google, okta, azuread, etc.
  • provider_subject / external user ID
  • user_id
  • tenant/org_id if applicable
  • email at time of linking
  • timestamps, status

This lets one user have:

• a password login
• one or more SSO identities

3) Link SSO accounts carefully

When a user signs in with SSO, you need to decide whether to:

• create a new account
• link to an existing account
• block the login until verified

Best practice:

• Match by verified email only if policy allows it
• Prefer an explicit “link account” flow when the user is already logged in
• For admins, allow pre-provisioning or just-in-time provisioning if desired

Avoid automatic linking just because emails match unless you trust the IdP and have strong verification, because email matching can be risky.

4) Preserve password login as a fallback

For every existing user:

• keep password auth enabled unless they explicitly opt out
• allow admins to enforce SSO only for specific orgs later
• provide recovery options:
  • password reset
  • backup admin account
  • secondary SSO or MFA recovery, depending on your policy

If you later support “SSO-only,” make that an org-level setting, not a global requirement.

5) Support org-level auth policy

Most SaaS apps need per-organization rules like:

• password allowed
• SSO allowed
• SSO required
• allowed IdPs/domains
• MFA required

Example:

• startup orgs: password + Google
• enterprise orgs: Azure AD only

This prevents breaking smaller customers while enabling enterprise rollout.

6) Handle email conflicts and account takeover risks

Be careful with:

• users who signed up with password using alice@company.com
• later SSO user arrives with the same email

Don’t assume they’re the same person unless:

• the email is verified by the IdP
• your policy explicitly allows domain trust
• you have an explicit linking step or admin approval

If in doubt:

• prompt the user to log into the existing account first and link SSO
• or send a secure link to the existing email address for verification

7) Add a migration path

A common rollout plan:

1. Ship SSO support alongside password login
2. Let users link SSO from settings
3. Support organization admin configuration
4. Gradually encourage SSO adoption
5. Optionally allow orgs to enforce SSO
6. Keep break-glass/admin recovery access

8) Use standards and a library

For SaaS, prefer:

• OIDC for modern web apps
• SAML only if you need enterprise compatibility

Use a well-tested auth library or managed identity provider if possible. Don’t hand-roll the protocol details.

9) UX patterns that work well

• Login page:
  • Email field
  • If domain matches an SSO-enabled org, show “Continue with SSO”
  • Otherwise show password login
• Account settings:
  • “Connected sign-in methods”
  • “Link SSO account”
  • “Set password” / “Reset password”
• Admin settings:
  • auth policy by org
  • domain allowlist
  • SSO enforcement toggle

10) Security checklist

• verify OIDC/SAML assertions properly
• protect against CSRF and replay
• use signed, short-lived tokens
• store only provider subject IDs, not access tokens unless needed
• log auth events
• support MFA where appropriate
• require email verification or IdP trust before linking

---

Recommended approach in one sentence

Add SSO as an alternative identity provider, keep password auth intact, link identities explicitly, and control enforcement at the organization level.

If you want, I can also sketch:

1. a database schema for password + SSO,
2. a login flow diagram, or
3. a migration plan for an existing SaaS app.