How do I integrate SSO without a full auth rewrite?

You can usually add SSO without rewriting your whole auth system by treating SSO as a new login source that maps into your existing user/session model.

The basic pattern

1. Keep your current auth/session system in place.
2. Add an SSO “entry point” that authenticates the user with your identity provider.
3. Map the SSO identity to a local user account in your app.
4. Issue your existing app session/token after SSO succeeds.

That way, SSO becomes just another way to reach the same internal authenticated state.

Common integration approaches

1) Frontend-only change, backend keeps session logic

If your app already uses server sessions:

• Add an endpoint like /auth/sso/start
• Redirect to the IdP
• Handle callback at /auth/sso/callback
• On success, create your normal session cookie

This is the least disruptive option.

2) Add SSO as a new auth provider

If you already support email/password:

• Keep password login
• Add buttons like “Continue with Okta/Google/Microsoft”
• Store a mapping like:
  • user_id
  • provider
  • provider_subject (the IdP’s unique user ID)
• If no match exists, link or create the account

3) Put SSO behind an auth gateway

If your app is hard to change:

• Use a reverse proxy / identity-aware proxy
• The proxy handles SSO
• Your app trusts headers or upstream auth context

This minimizes code changes, but you need to be careful about header spoofing and trust boundaries.

Best practices to avoid a rewrite

• Use OIDC/OAuth2 if possible, not custom SAML unless required.
• Keep your internal authorization model unchanged.
• Build a user-linking flow for existing accounts.
• Preserve your current roles/permissions and just attach them to the SSO-linked user.
• Make sure you have a fallback admin login during rollout.

Important migration decisions

• Account matching: match by email, employee ID, or explicit linking?
• Just-in-time provisioning: create users on first SSO login or pre-provision?
• Session format: keep current sessions or move to JWT later?
• Logout semantics: local logout vs global IdP logout

A practical rollout plan

1. Pick one IdP and one protocol, usually OpenID Connect.
2. Add a new login route and callback.
3. Link SSO identities to existing users.
4. Issue your current app session after SSO authentication.
5. Pilot with a small user group.
6. Expand and optionally deprecate passwords later.

If you want the least work

The shortest path is usually:

• OIDC for authentication
• existing app session for authorization
• one new identity table for provider-user mappings

If you want, I can sketch a concrete integration flow for your stack, like Node/Express, Django, Rails, .NET, Spring, or show how to do it with SAML vs OIDC.