How do I set up enterprise SSO for customers?

Setting up enterprise SSO for customers usually means offering customer identity federation so your customers’ employees can sign in to your app using their company IdP (Okta, Azure AD / Entra ID, Ping, Google Workspace, etc.). The most common approach is SAML 2.0 or OpenID Connect (OIDC), with a preference often depending on your customer base.

1) Pick the SSO model

There are two common patterns:

A. IdP-initiated / SP-initiated SSO

• SP-initiated: user goes to your app, you redirect to the customer’s IdP, then back to your app.
• IdP-initiated: user starts at the company portal and launches your app.

Most SaaS products support SP-initiated first because it’s easier to implement securely and consistently.

B. SAML vs OIDC

• SAML 2.0: still the most common for enterprise customer SSO.
• OIDC: simpler protocol, better developer ergonomics, increasingly common.

If you want maximum enterprise compatibility, support SAML first, then add OIDC if you can.

---

2) Define tenancy and identity mapping

You need a way to map an incoming SSO login to the right customer org.

Typical setup:

• A tenant/org in your app corresponds to a customer company.
• Each org stores:
  • IdP type (SAML or OIDC)
  • IdP metadata / issuer / certificates / client IDs
  • allowed domains (e.g. acme.com)
  • SSO enforcement settings
• Each user belongs to an org, or can be provisioned into one.

Key question: How do you know which org to use before login? Common options:

1. User enters email first (alice@acme.com) and you route based on domain.
2. Customer-specific login URL (e.g. acme.yourapp.com).
3. “Choose your company” page for multi-tenant apps.

Email-domain routing is the most common.

---

3) Build the SSO connection flow

Admin setup flow

Give the customer admin a setup page where they can:

• select SAML or OIDC
• enter IdP metadata or configuration
• upload certificate / configure redirect URIs
• test the connection
• enable “require SSO for this domain/org”

SAML setup inputs you’ll typically need

From the customer:

• IdP metadata XML or:
  • IdP entity ID
  • SSO URL
  • signing certificate
• optionally:
  • logout URL
  • nameID format
  • attribute mapping

From you, provide:

• ACS URL (assertion consumer service)
• Entity ID / audience
• SP metadata XML
• optional SLO URL

OIDC setup inputs you’ll typically need

From the customer:

• Issuer URL
• Client ID
• Client secret (if using confidential clients)
• scopes and claims configuration

From you, provide:

• Redirect URI(s)
• Post-logout redirect URI
• expected issuer/audience

---

4) Implement secure login handling

Regardless of protocol:

• Verify signatures
• Validate issuer, audience, timestamps, and nonce/request IDs
• Prevent replay attacks
• Bind the login response to the initiated auth request
• Use short-lived auth assertions/tokens
• Store sessions securely

For SAML

Validate:

• XML signature
• Issuer
• AudienceRestriction
• Recipient
• NotBefore / NotOnOrAfter
• InResponseTo if SP-initiated

Map identity using:

• NameID or
• email attribute (email, mail, userprincipalname)

For OIDC

Validate:

• ID token signature against JWKS
• iss
• aud
• exp, iat
• nonce
• state for browser flow

Map identity using:

• email claim and email_verified
• sub as stable external identifier

---

5) Support account linking and provisioning

Enterprise SSO often needs just-in-time provisioning or SCIM.

JIT provisioning

When a valid SSO login happens:

• if user doesn’t exist, create them
• assign them to the org
• optionally assign default role

SCIM provisioning

For larger customers, support SCIM 2.0 so they can:

• create users automatically
• deprovision users
• manage groups/roles

This is highly desirable for enterprise readiness.

---

6) Handle authorization and access control

SSO only proves identity. You still need authorization:

• roles: admin, member, viewer, etc.
• group mapping from IdP groups/claims
• org-level restrictions
• domain restrictions for signup/login
• optional MFA requirements via IdP policies

Be careful not to assume everyone in the IdP should get full access.

---

7) Add an enforcement policy

Customers often want to require SSO.

Common policies:

• Optional SSO: users can log in with password or SSO
• SSO required for org: only SSO users can access
• Domain-restricted: only verified domain users can join
• Password disabled for enterprise orgs

Also decide:

• what happens if the IdP is down?
• is there a break-glass admin account?
• how do admins update SSO settings if locked out?

Always keep a secure fallback admin access process.

---

8) Testing and support

Provide:

• a “Test SSO” button
• clear error messages
• downloadable metadata
• logs for failed assertions/tokens
• a support checklist:
  • correct ACS/redirect URI
  • clock skew
  • certificate rollover
  • correct attributes/claims
  • correct app assignment in IdP

Certificate and key rotation is a major source of failures, so design for:

• multiple signing certs
• metadata refresh
• overlap during rotation

---

9) Recommended implementation stack

A common practical approach:

• Use a proven identity library/provider rather than rolling your own parser/validator.
• Consider a customer identity platform if you want to move faster:
  • Auth0/Okta Customer Identity
  • WorkOS
  • Clerk
  • OneLogin
  • Azure AD B2C / Entra External ID, depending on use case

If you’re building it yourself:

• SAML: use mature libraries in your language
• OIDC: use standard OAuth/OIDC libraries
• Add audit logging and strong validation

---

10) A simple product checklist

Minimum viable enterprise SSO:

• Org/tenant model
• Email-domain based routing
• SAML support
• Admin setup page
• Metadata import/export
• SP-initiated login flow
• Secure assertion validation
• JIT user provisioning
• SSO enforcement per org
• Audit logs

Enterprise-ready:

• OIDC support
• SCIM provisioning
• Group/role mapping
• Certificate rotation support
• Multi-tenant IdP configs
• Break-glass admin access
• SSO troubleshooting dashboard

If you want, I can also give you:

1. a reference architecture for SaaS customer SSO,
2. a SAML implementation checklist, or
3. sample flows for Okta / Azure AD / Google Workspace.