I’m unhappy with our custom login flow. How do I replace it with SSO without a big rewrite?

You can usually replace a custom login flow with SSO incrementally by putting an identity provider in front of your app, then gradually moving authentication checks to it instead of rewriting the whole app.

The low-rewrite path

1) Pick an SSO provider and standard protocol

Use a provider that supports:

• OpenID Connect (OIDC) for modern web apps
• SAML if you’re integrating with enterprise systems

Common options:

• Auth0
• Okta
• Azure AD / Entra ID
• Google Workspace
• OneLogin

If you can choose, OIDC is usually the easiest to integrate.

---

2) Keep your app, replace only the login step

Instead of your app collecting passwords:

• redirect users to the identity provider
• let the provider authenticate them
• return to your app with a signed token or assertion

Your app then:

• validates the token
• creates or updates a local session
• continues as before

This avoids rewriting your whole UI and backend.

---

3) Map external identities to your existing users

To avoid changing your data model too much:

• add an external_identity_id field or mapping table
• associate provider subject IDs / email addresses with your current user records
• keep your internal user IDs and permissions model intact

That lets you preserve:

• roles
• profiles
• audit trails
• app-specific settings

---

4) Swap authentication, not authorization

A good migration strategy is:

• SSO handles who the user is
• your app still handles what they can do

So keep your current permission checks initially, and only change the login/authentication boundary.

---

5) Add a fallback during migration

For a smooth rollout:

• run SSO alongside the old login for a while
• allow only staff/internal users first
• add a “Login with SSO” button
• later make SSO the default
• finally retire password login

This reduces risk and helps with testing.

---

Typical implementation pattern

Frontend

• replace username/password form with “Sign in with SSO”
• redirect to /auth/login
• callback endpoint receives the auth response

Backend

• verify the token/signature
• check issuer, audience, expiry, nonce
• create session cookie
• optionally sync user profile fields

Database

• add:
  • sso_provider
  • sso_subject
  • last_login_at
• or create a separate identity linkage table

---

If you want the least rewrite possible

Use one of these approaches:

Option A: App-integrated OIDC

Best if you can change backend auth code.

• most flexible
• modern standard
• minimal UI changes

Option B: Reverse proxy / gateway SSO

Best if your app is hard to modify.

• put an auth-aware proxy in front
• proxy enforces login and passes identity headers to the app
• good for legacy apps
• be careful to trust headers only from the proxy

Option C: Embedded enterprise SAML integration

Best if your customers demand SAML.

• more enterprise-friendly
• sometimes more setup overhead than OIDC

---

Things to watch out for

• Account linking: avoid duplicate users when switching login methods
• Session management: make sure logout and token refresh are handled cleanly
• Email changes: don’t rely only on email as the permanent ID
• Security: validate tokens properly; don’t just decode them
• User provisioning: decide whether users are auto-created or pre-provisioned

---

A practical migration plan

1. Inventory current login flow and session handling
2. Choose OIDC provider
3. Add a new SSO login route
4. Link SSO identities to existing accounts
5. Keep old login as fallback
6. Migrate a pilot group
7. Monitor errors and account-linking issues
8. Remove password login once stable

---

If you tell me:

• your stack/framework
• whether this is internal users or customer-facing
• whether you need SAML or OIDC
• how your current sessions work

…I can suggest a concrete migration plan with the smallest code changes.