Can you recommend the best way to add SSO to a B2B SaaS app that already has username/password auth and needs SCIM plus role mapping?

Yes. For a B2B SaaS app with existing username/password auth, the best approach is usually to add a standards-based enterprise identity layer rather than building one-off integrations.

Recommended approach

1) Use OIDC (OpenID Connect) for SSO

For modern B2B SaaS, OIDC is the preferred SSO protocol for most enterprise customers because it’s easier to implement and maintain than SAML, while being widely supported.

• Primary SSO protocol: OIDC
• Optional support for SAML: if you expect large enterprise customers that still require it

2) Use SCIM 2.0 for provisioning

Since you need SCIM, implement SCIM 2.0 to handle:

• user provisioning
• user deprovisioning
• profile updates
• group membership / team syncing

This lets customer identity systems create and disable users automatically.

3) Add enterprise org-level identity configuration

Your SaaS should support identity settings at the tenant/org/workspace level, not just globally:

• SSO enabled per customer org
• one or more IdPs per org
• domain-to-org mapping for login discovery
• SCIM token or SCIM bearer auth per org
• organization-specific role mapping rules

---

Best architecture

Identity model

Keep your existing username/password auth, but introduce:

• User
• Organization/Tenant
• Membership
• Role
• Identity provider connection
• External identity mapping

Typical relation:

• A user can belong to multiple orgs
• Each org can have:
  • one SSO config
  • one SCIM config
  • role mapping rules
  • user/group mappings

Authentication flow

For enterprise users:

1. User enters email
2. You detect org by email domain or let them choose org
3. If SSO is enabled for that org, redirect to IdP via OIDC
4. On callback, create/link local user
5. Assign org membership and role based on claims or mapped groups

For non-SSO users:

• continue supporting username/password login

---

Role mapping recommendation

You have two common options:

Option A: Map IdP groups to app roles

Best for most B2B SaaS apps.

Example:

• Okta-Admins → org_admin
• Sales → member
• ReadOnly → viewer

This is usually the cleanest model because enterprise admins already manage groups in their IdP.

Option B: Map SCIM groups to roles

Useful if you want group membership to drive both provisioning and authorization.

• SCIM creates groups
• group membership determines app role
• app stores a mapping from external group ID/name to internal role

Recommendation

Use group-based role mapping with a fallback to user-claim mapping if groups aren’t available.

---

SCIM implementation guidance

Implement the core SCIM resources:

• /Users
• /Groups

Support at least:

• POST /Users
• PATCH /Users
• GET /Users
• DELETE /Users
• POST /Groups
• PATCH /Groups
• GET /Groups
• DELETE /Groups

Important behavior:

• Idempotency for retries
• Soft delete / deactivate users instead of hard delete
• Support active=false for deprovisioning
• Store external IDs separately from internal IDs
• Handle partial updates with PATCH correctly

---

SSO account linking strategy

This is important to avoid duplicate accounts.

Suggested logic

When a user logs in with OIDC:

• if a local account exists with matching verified email and same org, link it
• if not, create a new account and org membership
• if an existing password-based account exists, allow linking after verified email match or admin approval

Important

Don’t auto-link accounts on email alone unless the email is verified by the IdP and domain is controlled by the organization.

---

Security and product requirements

Security

• Use OIDC Authorization Code Flow with PKCE
• Verify issuer, audience, nonce, and signature
• Enforce email domain restrictions by org
• Require SCIM bearer token rotation
• Support SSO session logout if possible
• Log all admin identity changes

Product

• Self-serve SSO setup for admins
• Test connection button
• Metadata import for SAML if supported
• JIT provisioning via SSO login
• Audit log for provisioning and role changes
• Support fallback login for break-glass admin accounts

---

Build vs buy

Build it yourself if:

• you need deep customization
• you already have a solid auth platform
• enterprise identity is a core product capability

Use an identity platform if:

• you want faster time to market
• you don’t want to maintain SAML/SCIM edge cases
• your team is small

Common options:

• WorkOS — popular for SSO + SCIM + directory sync
• Auth0 Enterprise Connections — good if already on Auth0
• Okta CIC / Okta Workforce integration patterns
• FusionAuth — more self-host/control
• Clerk / Stytch — depending on enterprise feature needs

For many SaaS teams, WorkOS + your existing auth system is the fastest practical path.

---

My practical recommendation

If you want the most maintainable solution:

1. Keep username/password auth for SMB and fallback access
2. Add OIDC SSO for enterprise customers
3. Implement SCIM 2.0 for provisioning
4. Use IdP group claims for role mapping
5. Model identity settings at the tenant/org level
6. Consider using WorkOS or a similar provider unless identity is a major in-house competency

---

Suggested rollout plan

Phase 1

• Add OIDC SSO
• Link users by verified email
• Support org-level SSO settings

Phase 2

• Add SCIM user provisioning and deprovisioning
• Add group sync
• Add role mapping rules

Phase 3

• Add SAML if needed
• Add advanced domain discovery
• Add multiple IdP support per tenant
• Add audit exports and admin automation

---

If you want, I can also give you:

1. a recommended data model for users/orgs/roles/IdP connections, or
2. a step-by-step implementation plan for OIDC + SCIM in your stack.