We’re stuck supporting per-customer login exceptions. How do we move to a real SSO setup?

Moving from per-customer login exceptions to real SSO is mostly a process + architecture shift. The goal is to stop treating auth as a special case for each customer and instead make identity integration a standard capability.

1) Define the target SSO model

Decide what “real SSO” means for your product:

• Supported protocols: usually SAML 2.0, OIDC/OAuth2, or both
• Identity providers (IdPs): Okta, Azure AD/Entra, Google Workspace, Ping, OneLogin, etc.
• Just-in-time provisioning: create users on first login vs. pre-provision
• SCIM provisioning: automate user/group lifecycle if needed
• Account linking rules: how an SSO identity maps to an existing local account
• MFA/conditional access: whether you defer to the customer IdP policies

If you don’t define these up front, you’ll just recreate “exceptions” under a new name.

---

2) Standardize on a single auth architecture

Pick one of these patterns:

Option A: Use a broker / identity platform

Use Auth0, Okta CIC, Azure AD B2C, WorkOS, Clerk, etc. as a layer between your app and customer IdPs.

Pros

• Fastest route
• Less custom SAML/OIDC handling
• Easier multi-tenant setup

Cons

• Ongoing platform cost
• Some vendor lock-in

Option B: Build direct IdP integrations

Your app directly supports SAML/OIDC per tenant.

Pros

• More control
• Lower vendor dependency

Cons

• More engineering and maintenance
• Harder edge-case handling

If you’re currently drowning in one-off exceptions, a broker is often the pragmatic first step.

---

3) Make tenant identity configuration self-service

This is the biggest operational win.

Create an admin UI where a customer can configure:

• IdP type: SAML or OIDC
• Issuer / metadata URL / client ID
• Signing certificates or discovery endpoints
• SSO enforcement mode:
  • optional
  • required for certain users
  • required for all users
• Email domain(s) tied to the tenant
• Role/group mapping
• SCIM settings if supported

The support team should not be editing auth settings by hand for each customer.

---

4) Design a clear account-matching policy

A lot of “SSO exceptions” are really user identity matching problems.

Common rules:

• Match on email address as the primary identifier
• If email changes, support admin-controlled relinking
• For enterprise tenants, require verified domain ownership before linking
• Prevent ambiguous matches across tenants
• For IdP assertions, trust a stable immutable ID when possible:
  • SAML NameID / OIDC sub
  • but still store email as a display/notification field

You need a deterministic policy for:

• first login
• existing user migration
• duplicate accounts
• changed email domains
• deactivated IdP users

---

5) Plan migration from local auth to SSO

Don’t flip everyone at once.

Recommended migration path

1. Add SSO alongside current login
   • Keep password login available initially
   • Enable SSO per tenant
2. Pilot with a few design partners
   • Choose customers with mature IdPs and admin support
3. Migrate users gradually
   • Link existing accounts to SSO identities
   • Validate access, roles, and audit logs
4. Introduce SSO enforcement
   • For selected tenants, disable password login
5. Deprecate exception handling
   • Move edge cases into supported configuration, not code paths

---

6) Build for enterprise controls

To make SSO actually usable for customers, support the things enterprises expect:

• SP-initiated login and optionally IdP-initiated
• Logout behavior and session expiration policies
• Audit logs for login events, linking, failures, provisioning
• Role/group mapping
• Multi-factor enforced at IdP
• Domain verification
• Service account strategy for integrations/jobs that can’t use human SSO
• Break-glass admin access so you don’t lock yourself out

That last one is important: always have at least one secure non-SSO recovery path for tenant admins.

---

7) Remove support dependency from the flow

A “real SSO setup” usually means:

• customer admin can configure it without engineering involvement
• support can troubleshoot with clear logs and error codes
• your app has a standard test flow:
  • “Test SSO connection”
  • “Preview attribute mappings”
  • “Validate domain ownership”
• errors are actionable:
  • invalid certificate
  • audience mismatch
  • bad ACS URL
  • unverified domain
  • unknown email
  • group mapping failure

If support is still translating custom config into app behavior, you haven’t really escaped exceptions.

---

8) Instrument and monitor

You’ll want visibility into:

• login success/failure rates by tenant
• SAML/OIDC error reasons
• time to first successful SSO login
• provisioning failures
• account-linking events
• tenants still on password auth

This helps you find the remaining exception patterns and productize them.

---

9) Define the exception policy

Some exceptions may remain unavoidable, but they should be bounded.

Examples of acceptable supported exceptions:

• a customer has multiple IdPs during acquisition integration
• a subsidiary needs separate domains
• a service account must bypass SSO
• temporary coexistence during migration

What you want to avoid:

• custom code for one customer’s login flow
• manual DB edits
• unique auth logic per tenant

A good rule: if you’ve done the same “exception” more than 3 times, it becomes a product requirement.

---

10) A practical rollout plan

Here’s a sensible sequence:

Phase 1: Foundation

• pick broker or direct strategy
• implement SAML/OIDC core flow
• store tenant-level auth configuration
• add audit logs and error handling

Phase 2: Self-service

• build admin config UI
• support domain verification
• support test connection and mapping preview

Phase 3: Migration

• onboard 2–5 pilot tenants
• support account linking and JIT provisioning
• create docs and support runbooks

Phase 4: Enforcement

• allow tenant-level SSO-required mode
• disable password auth for those tenants
• add SCIM if needed

Phase 5: Cleanup

• remove one-off login branches
• move old “exceptions” into standard settings
• track remaining nonstandard customers

---

11) Questions to answer before implementation

To avoid rework, decide these early:

1. Do you need SAML, OIDC, or both?
2. Will you use a broker or build direct integrations?
3. How will users be matched: email, immutable subject, or both?
4. Will you support JIT provisioning?
5. Do you need SCIM for lifecycle management?
6. Can tenants require SSO for everyone, or just some users?
7. How will you handle existing accounts and duplicates?
8. What’s the fallback if the IdP is down?
9. How do admins recover access if SSO is misconfigured?
10. What is your deprecation timeline for local login exceptions?

---

If you want, I can also help you with one of these:

• a reference SSO architecture
• a migration plan from custom logins to SSO
• a tenant config schema
• a support checklist for SAML/OIDC onboarding