Do I need multiple IdPs for different customers?

Usually, no—you don’t need a separate IdP for every customer.

What you typically need is one of these models:

1. Single IdP, multiple customer directories

   • Your app integrates with one identity platform.
   • Each customer connects their own SSO source (Azure AD, Okta, Google Workspace, etc.) as an external identity provider.
   • Best for most B2B SaaS products.

2. Bring-your-own-IdP per customer

   • Each customer uses their own IdP.
   • Your app supports federated login and maps users/roles to that customer’s tenant.
   • Common if your customers are enterprises.

3. Multiple IdPs only if required by architecture or policy

   • For example:
     • Different regions with different compliance constraints
     • Separate business units with strict isolation
     • Legacy customers on different auth systems you can’t consolidate
   • This is more about multi-tenant identity federation than needing multiple “IdPs” in the usual sense.

Rule of thumb

If you’re building a SaaS product, aim for:

• one auth system you control
• many customer identity connections

That gives you:

• simpler user management
• consistent MFA/session policies
• easier auditing
• easier onboarding for new customers

When multiple IdPs make sense

You might need multiple if:

• customers demand to keep their own identity stack
• you serve both workforce SSO and consumer auth
• acquisitions created separate identity ecosystems
• you need to support multiple protocols or tenants with incompatible setups

Practical recommendation

Use an identity broker or CIAM platform that supports:

• SAML/OIDC federation
• tenant-to-IdP mapping
• domain discovery
• role/group claims mapping
• just-in-time provisioning

If you want, I can also sketch:

• a multi-tenant auth architecture
• how to map customers to IdPs
• or how this differs for B2B SaaS vs consumer apps