How do I build enterprise auth without custom per-customer code?

To build enterprise auth without custom per-customer code, design around standard protocols + tenant-specific configuration + policy layers, not one-off integrations.

Core approach

1) Support the standards first

Implement:

• SAML 2.0 for enterprise SSO
• OIDC / OAuth 2.0 for modern IdPs
• Optional: SCIM 2.0 for provisioning/deprovisioning

This covers most enterprise customers without custom logic.

---

2) Make auth tenant-configurable

Model each customer as a tenant with config such as:

• IdP type: Okta, Azure AD, Ping, Google Workspace, etc.
• SAML metadata / OIDC issuer
• client ID / secret
• ACS / redirect URIs
• allowed email domains
• claim mappings
• group-to-role mappings
• JIT provisioning enabled/disabled
• enforcement mode: optional, required, or domain-based

Your code should read tenant config and behave generically.

---

3) Use a single auth pipeline

Build one login flow that:

1. Identifies tenant
2. Redirects to the right IdP
3. Validates assertion/token
4. Maps external identity to internal user
5. Applies authorization policies

No per-customer branching beyond configuration lookup.

---

4) Separate authentication from authorization

Don’t bake enterprise-specific access rules into auth code.

Use:

• AuthN: who is the user?
• AuthZ: what can they do?

Store roles/permissions internally and map IdP claims/groups into them.

---

5) Support Just-in-Time provisioning

When a user logs in:

• create account if missing
• attach tenant
• assign default role
• optionally require admin approval

This avoids bespoke user sync for every customer.

---

6) Add SCIM for lifecycle management

For larger customers, SCIM handles:

• create user
• update attributes
• disable user
• group sync

This reduces custom work and gives enterprise-grade behavior.

---

Recommended architecture

Tenant model

• tenant_id
• auth_mode = password | sso | mixed
• idp_protocol = saml | oidc
• idp_metadata_url / issuer
• domain_whitelist
• claim_rules
• group_mapping
• scim_enabled

Identity model

• user_id
• tenant_id
• external_subject
• email
• idp_provider
• status

Auth flow

• Resolve tenant by domain, subdomain, email domain, or organization selection
• Use tenant-specific IdP config
• Validate assertion/token
• Match by immutable external subject if possible
• Fallback to verified email
• Provision/update user record

---

Key design principles

Prefer configuration over code

Expose admin UI or API for:

• uploading SAML metadata
• entering OIDC settings
• mapping claims/groups
• toggling SSO enforcement

Normalize identity data

Different IdPs send different claims. Normalize into:

• external_subject
• email
• given_name
• family_name
• groups
• tenant_roles

Be conservative with account linking

Avoid auto-linking users based only on email unless the tenant controls the domain and trust boundary is clear.

Plan for multiple IdPs per tenant

Some enterprises have:

• multiple domains
• mergers
• regional IdPs

Support multiple connections per tenant if possible.

---

What usually causes custom code

Avoid:

• hardcoded customer-specific claim names
• custom MFA logic per tenant
• bespoke approval flows in auth itself
• customer-specific user sync jobs
• provider-specific branching in app code

Instead, make those behaviors configurable.

---

Practical implementation options

If you want to move fast, use:

• Auth0 / Okta Customer Identity / Azure AD B2C / WorkOS / Clerk / FusionAuth / Keycloak
• For B2B enterprise SSO specifically, WorkOS is common because it abstracts SAML/OIDC/SCIM patterns well.

If you build it yourself, invest in:

• SAML/OIDC libraries
• tenant metadata management
• SCIM endpoints
• audit logs
• replay protection / signature validation / clock skew handling

---

Minimal viable enterprise auth

If you want the smallest useful version:

1. SSO via SAML + OIDC
2. Tenant configuration UI
3. JIT provisioning
4. Domain-based tenant routing
5. Group-to-role mapping
6. SCIM later

---

Rule of thumb

If you find yourself writing “for Customer X do Y,” stop and ask:

• Can this be expressed as tenant config?
• Can the IdP send a claim or group for it?
• Can authorization handle it instead of authentication?

If you want, I can sketch:

1. a reference architecture,
2. a database schema, or
3. a login flow pseudocode for enterprise auth.