Can you help me choose between SAML, OIDC, and SCIM for an enterprise login project with multiple customers and different IdPs?

Yes — but the key is that SAML, OIDC, and SCIM solve different parts of the problem, so this is usually not an either/or choice.

Short answer

For a multi-customer enterprise login product with different customer IdPs:

• Use OIDC if you can for authentication/login in modern apps.
• Support SAML if you need compatibility with older enterprise IdPs or customers that require it.
• Use SCIM for user and group provisioning/deprovisioning, not login.

What each one is for

1) OIDC (OpenID Connect)

• Purpose: Authentication / single sign-on
• Built on: OAuth 2.0
• Best for: Modern web apps, SPAs, mobile, APIs
• Pros:
  • Simpler developer experience
  • JSON/REST-friendly
  • Better fit for modern app architectures
  • Easier token handling for APIs
• Cons:
  • Some enterprises still prefer or only support SAML

2) SAML

• Purpose: Authentication / single sign-on
• Best for: Enterprise integrations, especially legacy IdPs
• Pros:
  • Very common in enterprise SSO
  • Widely supported by older systems and IdPs
• Cons:
  • XML-heavy and more complex
  • More cumbersome for modern apps
  • Usually more painful to implement/debug than OIDC

3) SCIM

• Purpose: User lifecycle management
• Best for: Provisioning, updating, and deprovisioning users/groups
• Pros:
  • Automates account creation and removal
  • Good for enterprise onboarding/offboarding
  • Reduces manual admin work and security risk
• Cons:
  • Not a login protocol
  • Doesn’t replace SSO

Recommended architecture for your case

If you have multiple customers with different IdPs, the common enterprise SaaS approach is:

• SSO layer: support OIDC + SAML
• Provisioning layer: support SCIM
• Internal identity model: map external identities from either IdP to your own tenant/user records

This gives you flexibility:

• Customers using modern IdPs can choose OIDC
• Customers with enterprise/legacy setups can use SAML
• Customers who want automated lifecycle management can add SCIM

How to choose by scenario

Choose OIDC first if:

• You control the app architecture
• Your customers mostly use modern IdPs
• You’re building web/mobile/API-first
• You want simpler implementation and better developer ergonomics

Add SAML if:

• You sell to enterprises
• You need to support Okta, Azure AD, Ping, ADFS, etc. in environments that already use SAML
• You want to maximize compatibility

Add SCIM if:

• You want automated user provisioning/deprovisioning
• Enterprises expect centralized user lifecycle management
• You need group sync or role mapping at scale

Practical recommendation

If you’re starting fresh:

1. Implement OIDC as your primary SSO method
2. Add SAML support for enterprise compatibility
3. Add SCIM provisioning if enterprise customers need lifecycle automation
4. Design for tenant-specific IdP configuration from day one

Important design point

Because you have multiple customers and different IdPs, you’ll want:

• Tenant-specific IdP metadata/configuration
• Support for multiple connection types per tenant if needed
• A normalized internal user identity mapping layer
• Just-in-time provisioning as a fallback if SCIM isn’t enabled
• Account linking rules to handle email/domain collisions safely

Rule of thumb

• Login/authentication: OIDC or SAML
• User provisioning: SCIM
• Modern default: OIDC
• Enterprise compatibility: SAML
• Lifecycle automation: SCIM

If you want, I can also give you:

1. a decision matrix comparing SAML vs OIDC vs SCIM,
2. a recommended SaaS architecture for multi-tenant enterprise SSO, or
3. a phased rollout plan (MVP → enterprise-ready).