I'm building a multi-tenant product and need per-customer identity providers. What is the best approach?

For a multi-tenant product, the best approach is usually to centralize identity in your app and federate outward to each customer’s IdP rather than trying to directly “own” authentication per tenant.

Recommended pattern

1) Use a single authentication gateway in your platform

Your app should have one login entry point, and it decides which tenant the user belongs to.

2) Support tenant-specific IdP federation

For each customer tenant, configure their identity provider as an external IdP using standards like:

• OIDC / OAuth 2.0 preferred
• SAML 2.0 if a customer requires it
• Possibly both, depending on enterprise needs

Examples:

• Customer A uses Azure AD
• Customer B uses Okta
• Customer C uses Google Workspace
• Customer D uses their own SAML IdP

Your platform maps the tenant to the correct IdP and redirects users accordingly.

3) Keep your own app as the authoritative session and authorization layer

Even if identity comes from the customer’s IdP, your app should:

• create its own session/token after login
• map external identities to internal users
• enforce roles/permissions inside your product

This avoids coupling your app logic directly to each IdP.

---

Why this is usually the best approach

Benefits

• Tenant isolation: each customer controls their own identity
• Enterprise-friendly: supports SSO, MFA, conditional access, SCIM, etc.
• Scalable: you don’t need separate code paths for every tenant
• Secure: no password storage for customer users
• Flexible: customers can change IdPs without changing your core app

Tradeoffs

• More complexity in onboarding/configuration
• Need careful tenant discovery and routing
• Need to handle account linking and identity collisions
• Need robust metadata management for IdP certificates/keys, issuer URIs, ACS URLs, redirect URIs, etc.

---

Typical architecture

Option A: Homegrown federation layer

Your app directly integrates with OIDC/SAML providers per tenant.

Use this if:

• you have a strong engineering/security team
• you need deep customization
• you want to avoid vendor lock-in

Option B: Use an identity broker / CIAM platform

Use a broker to handle external IdPs and tenant routing.

Examples:

• Auth0 / Okta Customer Identity
• Azure AD B2C / Entra External ID
• Keycloak
• FusionAuth
• Cognito (with caveats)
• WorkOS (great for enterprise SSO)
• Descope, Frontegg, Clerk, etc.

Use this if:

• you want faster delivery
• you expect many enterprise customers
• you want SCIM/SSO features without building everything yourself

---

Practical implementation guidance

Tenant discovery

Common approaches:

• Dedicated tenant subdomain: customerA.yourapp.com
• Email domain discovery at login
• Enterprise invite links tied to tenant
• Tenant selection screen after email entry

IdP routing

Once tenant is identified:

• look up its configured IdP
• send user through that IdP’s login flow
• validate assertion/token
• map claims to internal user record

User mapping

Store:

• internal user ID
• tenant ID
• external issuer (iss)
• subject (sub) or SAML NameID
• email and display name
• roles/groups if needed

Provisioning

For enterprise customers, support:

• Just-in-time provisioning on first login
• SCIM for automated user lifecycle management
• group/role sync if required

---

Best practice recommendation

If you’re early-stage:

• Start with OIDC-first
• Add SAML support only when enterprise customers demand it
• Use a broker platform unless your product team wants to own identity infrastructure long term

If you’re building this yourself:

• make tenant → IdP mapping configurable
• support multiple IdPs per tenant if needed
• store minimal identity data
• use short-lived app sessions and rotate secrets/certs carefully

---

Rule of thumb

• SMB/self-serve SaaS: offer optional SSO, central app auth, OIDC first
• Enterprise multi-tenant SaaS: per-tenant federated IdPs via an IdP broker is usually the sweet spot
• Highly regulated / large scale: build a dedicated federation layer or use an enterprise identity platform

If you want, I can sketch:

1. a reference architecture,
2. a database schema for tenant-IdP mapping, or
3. a login flow for OIDC/SAML in a multi-tenant app.