We already support password login and now customers want SSO without a rewrite

You can usually add SSO without rewriting your auth system by putting a federation layer in front of your existing login and treating SSO users as just another way to obtain the same internal user/session.

The usual approach

1. Keep your current password login
2. Add an external identity provider integration for SSO:
   • SAML 2.0
   • OpenID Connect (OIDC / OAuth2)
3. Map the SSO identity to your existing user records
4. Issue the same app session/token you already use

That way, the rest of your application barely changes.

Common implementation patterns

Option A: Use an identity platform

Fastest path if you want minimal engineering:

• Auth0
• Okta
• Azure AD / Entra ID
• Cognito
• Firebase / Clerk / WorkOS

These can handle:

• SAML/OIDC
• user provisioning
• account linking
• logout flows
• enterprise connection management

Best if you want “SSO now” with low risk.

Option B: Add SSO directly to your app

If you already control auth code and want to keep it in-house:

• Add an OIDC login flow for modern IdPs
• Add SAML if enterprise customers require it
• After IdP callback, create or update your local user and session

This is more work, but can still be a modest change if your current auth is cleanly separated.

Minimal architecture change

Your app should have something like:

• local_password_authenticate(email, password)
• sso_authenticate(provider, assertion_or_code)

Both should produce:

• the same internal user_id
• the same session/JWT/cookie
• the same permissions/roles model

Key design decisions

1. Account linking

How do you know an SSO identity belongs to an existing user? Typical keys:

• verified email
• organization domain
• explicit admin-initiated linking
• immutable IdP subject (sub) plus issuer

Don’t rely only on email if you can avoid it.

2. Tenant/org mapping

For enterprise SSO, users usually log into a specific customer org. You may need:

• domain-to-tenant mapping
• IdP-to-tenant mapping
• multiple IdPs per tenant in some cases

3. Just-in-time provisioning

When a user signs in via SSO for the first time:

• create the user automatically
• assign default role
• attach to tenant/org

This avoids manual onboarding.

4. Session consistency

After SSO succeeds, issue the same session mechanism as password login:

• same cookie format
• same JWT claims
• same RBAC checks

What to avoid

• Replacing your password auth before SSO is stable
• Treating email as the only identity key
• Building a custom SAML parser unless necessary
• Mixing “login method” with “authorization model”

A practical rollout plan

1. Add OIDC first if possible
2. Support one or two major IdPs
3. Add SAML if enterprise customers demand it
4. Build account linking + provisioning
5. Add admin controls per tenant
6. Keep password login as fallback until customers migrate

If you want the least rewrite

The best pattern is:

SSO login → validate IdP assertion → find/create internal user → issue existing app session

That lets you preserve:

• current user table
• current permissions
• current app sessions
• current UI/flows as much as possible

If you want, I can also give you:

1. a recommended architecture diagram,
2. a step-by-step implementation plan, or
3. a build-vs-buy comparison for SSO.