How do I build SSO for a SaaS product with existing users?

Building SSO for a SaaS product with an existing user base is mostly an identity-linking and rollout problem, not just a protocol problem. The main challenge is: how do you connect a new SSO identity to accounts that already exist without creating duplicates or locking people out?

Here’s a practical way to approach it.

---

1) Decide what “SSO” means for your product

Most SaaS products offer one or more of these:

• SAML 2.0 for enterprise customers
• OIDC / OAuth2 for modern identity providers
• Sometimes both

For enterprise SaaS, the common pattern is:

• SSO for authentication
• SCIM for provisioning/deprovisioning if you need automated user lifecycle management

If you’re starting fresh, OIDC is simpler to implement. If your customers expect enterprise IdPs like Okta, Azure AD, Ping, ADFS, SAML is still very common.

---

2) Model identity separately from the user account

Do not treat “email” as the primary identity. Emails change, and the same email can be used across identity providers in different ways.

Use something like:

• User
  • internal app user record
  • id, email, name, status, etc.
• Identity
  • user_id
  • provider_type (saml, oidc)
  • provider_name / tenant
  • external_subject_id (sub for OIDC, NameID / immutable identifier for SAML)
  • metadata like issuer, tenant, timestamps

A single user can have multiple linked identities.

This makes it easy to support:

• local password login
• SSO login
• account linking
• multiple IdPs for one org, if needed

---

3) Plan how existing users will be matched to SSO identities

This is the most important part.

Common strategies:

A. Match by verified email

When the user signs in with SSO, you get an email from the IdP, and if it matches an existing account, link them.

Pros:

• Easy
• Good UX

Cons:

• Can be risky if email trust is weak
• Some IdPs don’t guarantee email immutability
• Email may not be verified or may differ

Use this only if:

• you trust the IdP
• you verify the email claim
• you’re okay with some operational controls

B. Admin-initiated account linking

The org admin pre-links users or invites users, and then SSO login attaches to that existing account.

Pros:

• Safer
• Better for enterprise onboarding

Cons:

• More setup work

C. Just-in-time provisioning with domain claim

If a user logs in with an IdP and their email domain belongs to a claimed org, create or link the account.

Pros:

• Smooth onboarding
• Works well with enterprise orgs

Cons:

• Domain ownership logic must be solid
• Not ideal for consumer-style SaaS

Best practice

For existing users, use a controlled linking flow:

1. User logs in with password or magic link.
2. User goes to settings and adds SSO.
3. Admin verifies the domain / configures the IdP.
4. Existing accounts are linked using verified email or an admin-approved process.
5. Future logins use SSO.

This avoids accidental takeover.

---

4) Add an organization layer if you don’t already have one

SSO is usually configured per customer org, not per individual user.

Recommended model:

• Organization

  • id
  • name
  • domains
  • SSO settings
  • enforcement mode

• Membership

  • user_id
  • org_id
  • role
  • status

• SSO Connection

  • org_id
  • provider type
  • issuer
  • SAML metadata / OIDC config
  • certificate / client id / secret
  • enforcement flags

This helps you support:

• one company with many users
• multiple orgs with different IdPs
• optional or enforced SSO per org

---

5) Decide your migration mode for existing users

You generally have 3 rollout modes:

Mode 1: Optional SSO

Users can log in with password or SSO.

Good for:

• gradual rollout
• lower-risk migration

Mode 2: Dual login with linking

Existing users can still use password, but admins can enable SSO and link users over time.

Good for:

• medium-sized customer base
• gradual migration

Mode 3: SSO enforced

Password login is disabled for an org after migration.

Good for:

• mature enterprise setup
• security requirements

Most SaaS products do:

1. optional SSO
2. link existing users
3. enforce SSO later

---

6) Build a safe account linking flow

Never auto-link purely on an untrusted assertion unless you are sure it’s safe.

A safe linking flow looks like this:

For admins

• Admin configures SSO in your app.
• They provide IdP metadata or client credentials.
• You verify the connection.
• You show the admin which domain(s) will be used.
• Admin can invite or import users.

For end users

• User clicks “Sign in with SSO.”
• If an existing account matches by verified email, you can:
  • require the user to already be signed in, or
  • send an email confirmation to the existing address, or
  • ask them to sign in once with password before linking
• After confirmation, create the identity link.

Avoid

• creating a new account and linking silently based only on email if the domain is not claimed
• allowing a different IdP to claim an existing user without verification

---

7) Support account takeover prevention

A common risk is: someone logs in with an IdP using an email that matches an existing user.

Mitigations:

• only trust email if it’s from a verified/claimed domain
• require admin setup for the org
• verify the IdP issuer and tenant
• link identities only after user confirmation or admin approval
• keep a record of how the identity was linked

Good audit trail:

• who linked it
• when
• from which provider
• by admin action or user action

---

8) Handle login routing carefully

You need a way to route users to the right SSO connection.

Common options:

• Email-domain discovery
  • user enters email first
  • you look up domain -> org -> SSO connection
  • then redirect to IdP
• Org-specific login URL
  • app.com/login/acme
  • best for enterprise
• IdP-initiated login
  • supported but usually less ideal as the primary flow

A common pattern:

1. user enters email
2. if domain matches an SSO-enabled org, show “Continue with SSO”
3. otherwise show password login or magic link

---

9) Implement a fallback and recovery path

SSO outages happen. IdP config breaks. Certificates expire.

You need a recovery strategy:

• break-glass admin account
• support-driven recovery process
• ability to temporarily disable SSO enforcement
• clear error messages for users
• monitoring for metadata/cert expiration

For admin accounts, many SaaS companies keep:

• at least one non-SSO admin
• or tightly controlled recovery access

---

10) If you use SAML, be careful with the following

SAML has more enterprise complexity.

Important items:

• validate XML signatures correctly
• check audience, issuer, recipient, and time conditions
• use immutable identifiers, not email, as the true identity key if possible
• beware of clock skew
• support certificate rotation
• decide whether you accept SP-initiated, IdP-initiated, or both

For existing users, SAML linking often uses:

• NameID or another stable claim
• plus verified email for display/matching
• admin approval for first link

---

11) If you use OIDC, be careful with the following

OIDC is simpler, but still make sure you:

• validate the ID token signature
• validate iss, aud, exp, nonce
• store sub as the stable identifier
• don’t rely on email as the permanent key
• understand whether email_verified is present and trustworthy

For linking, the OIDC sub is the main identity anchor.

---

12) Recommended rollout plan for an existing SaaS

A practical migration approach:

Phase 1: Infrastructure

• add org model if needed
• add identities table
• add SSO connection config
• add audit logs

Phase 2: Optional SSO

• support one protocol first, ideally OIDC or SAML depending on customer demand
• allow admins to configure SSO
• allow login via SSO and password

Phase 3: Controlled linking

• let admins link existing users
• allow users to link their own accounts after re-authentication
• add domain claim verification

Phase 4: Enforcement

• per-org toggle to require SSO
• disable password login for that org
• keep recovery path

Phase 5: Provisioning

• add SCIM if needed
• automate user creation, deactivation, and group sync

---

13) UX patterns that work well

Good UX matters a lot here.

Useful screens:

• “Sign in with email”
• “We found SSO for your domain”
• “Connect your organization’s identity provider”
• “Link your existing account to SSO”
• “SSO is required for your organization”

Helpful user feedback:

• “Use your work email”
• “This email belongs to an SSO-enabled organization”
• “Contact your admin”
• “You’re signed in, now confirm to link this account”

---

14) A simple data model example

users
- id
- email
- name
- status
- created_at

organizations
- id
- name
- created_at

memberships
- id
- user_id
- org_id
- role
- created_at

sso_connections
- id
- org_id
- provider_type
- issuer
- entity_id
- client_id
- metadata_url
- certificate
- enforced
- created_at

identities
- id
- user_id
- provider_type
- provider_key
- subject
- email
- email_verified
- created_at
- last_login_at

audit_events
- id
- actor_user_id
- org_id
- event_type
- details_json
- created_at

---

15) Security checklist

• Validate all SSO assertions/tokens
• Store stable identifiers, not just email
• Require explicit linking for existing users
• Keep audit logs
• Support certificate/client secret rotation
• Have break-glass access
• Enforce least privilege on admin actions
• Verify domain ownership before auto-linking
• Handle logout carefully, but don’t depend on it for security

---

16) Suggested implementation order

If you want the shortest path to production:

1. Add org-level SSO configuration
2. Add identity table
3. Build one protocol integration
4. Implement email-domain discovery
5. Add safe account linking
6. Add admin controls for enforcement
7. Add audit logs and recovery
8. Add SCIM later if needed

---

17) The key design principle

For existing users, the biggest rule is:

Do not let the SSO provider silently take over an existing account without a trusted linking step.

That one decision prevents most account takeover and duplicate-account issues.

---

If you want, I can also give you:

1. a recommended architecture diagram,
2. a step-by-step SAML or OIDC flow, or
3. a migration plan for existing users in a live SaaS app.