How do I add SSO while keeping username/password login for smaller customers?

A good pattern is to support both:

• local username/password for smaller customers
• SSO for customers who want centralized identity

The key is to make them two authentication methods into the same user account model, rather than two separate account systems.

Recommended approach

1. Keep your existing username/password login

Continue supporting:

• email/username + password
• password reset
• MFA if you have it

This remains the default for customers who don’t need SSO.

2. Add SSO as an additional sign-in method

Support one or more common enterprise identity providers:

• SAML 2.0 for most enterprise customers
• OIDC / OpenID Connect for modern IdPs like Azure AD, Okta, Google Workspace, Auth0, etc.

For each customer, let them choose:

• Password only
• SSO only
• SSO + password fallback (if you want to allow both)

3. Use an organization-based account model

Usually this looks like:

• Organization / tenant
• Users
• Auth identities
  • local password identity
  • SSO identity (SAML/OIDC subject + issuer)

A user can belong to an org and have:

• one local login identity
• zero or more external identity links

4. Link SSO users to existing accounts

When someone signs in with SSO:

• identify their org from the SSO config
• map the SSO assertion/claim to an existing user email or immutable ID
• if user exists, attach the SSO identity
• if not, create a new user in that org

Important: use email matching carefully. Better if you can also verify:

• IdP issuer
• NameID / subject / immutable user ID
• domain ownership for the org

5. Add domain-based routing for convenience

If a customer’s email domain is known, you can:

• auto-detect SSO
• show “Continue with SSO” after email entry
• still offer password login for accounts that are local

Example flow:

1. user enters email
2. you check tenant settings for that domain
3. if SSO is enabled, show SSO button
4. if not, show password form

6. Decide on account policy per tenant

Support configurable policies:

• Local only
• SSO optional
• SSO required for some users/groups
• SSO required, with emergency/admin local account

For smaller customers, the simplest is:

• local auth enabled by default
• SSO can be turned on later
• optional “break-glass” admin password account kept local

Important security considerations

• Don’t let SSO users take over local accounts just because email matches unless the IdP and tenant are verified.
• Require admins to explicitly link SSO to the org.
• Store external identity with:
  • provider type
  • issuer
  • subject/NameID
  • org/tenant ID
• If you support password fallback, protect it with:
  • MFA
  • admin controls
  • audit logs

UI/UX recommendation

A simple login page:

• email field first
• if org uses SSO, show “Sign in with SSO”
• always allow password login only if that org/user is configured for local auth

This keeps the experience clean for enterprises while preserving simplicity for smaller customers.

Practical implementation model

A user record might look like:

• user_id
• org_id
• email
• password_hash (nullable)
• auth_methods:
  • local_password
  • saml
  • oidc
• external_identities:
  • provider
  • issuer
  • subject

That structure lets one user have both login types.

Suggested rollout plan

1. Add organization-level SSO settings
2. Support one protocol first (often OIDC or SAML)
3. Implement user identity linking
4. Add login-page discovery by email domain
5. Add admin controls for password fallback
6. Add audit logs and support tooling

If you want, I can also sketch:

• a database schema
• a login flow
• or a SAML/OIDC integration architecture for this setup.