B2B Enterprise SSO Onboarding: A 60-Day Playbook

The first $30–50k enterprise B2B SaaS contract typically arrives with a security questionnaire requiring SAML SSO. The SaaS that has it ready closes the deal weeks faster than the SaaS that has to ship it as a project. This playbook covers the 60-day path for landing one customer's Enterprise SSO end-to-end on a CIAM that supports per-Organization SSO.

Phase 1, Discovery and IdP confirmation (5 days)

Before configuring anything, confirm what you're integrating with. The most common cause of a stalled SSO onboarding is shipping configuration before understanding the customer's IdP, attribute schema, and procurement constraints. Five days of upfront discovery saves weeks of mid-project rework. The discovery checklist below covers the four artifacts you need before touching a connection.

IdP inventory. Which IdP does the customer run? Most common in 2026: Okta, Microsoft Entra, Google Workspace, Ping, OneLogin, JumpCloud. Each has slightly different SAML / OIDC configuration UX. The CIAM should ship pre-integrated templates for the major IdPs.

Protocol selection. Does the customer's procurement team specifically require SAML, or will OIDC work? In 2026 most modern IdPs support both; the customer's existing template may default to one. Confirm before building the integration.

Attribute requirements. What user attributes does your application need at first login, email, name, groups, employee ID, department? The IdP's assertion must include these; your CIAM must map them to your user schema. Document the required attributes before configuration.

Domain restrictions. Will the customer require email-domain-restricted access (only @customer.com addresses can authenticate to their Org)? Most CIAM ship this as a configuration option per-Org.

Phase 2, Self-service connection setup (10 days)

The customer's IT admin should be able to configure the SSO connection without your engineering team's involvement. This is the difference between a 60-day onboarding and a 6-week back-and-forth.

Self-service Admin Portal. Frontegg, Auth0 B2B Organizations, WorkOS, and SSOJet ship an embedded admin portal where the customer's IT admin uploads their SAML metadata XML or pastes their OIDC discovery URL. The portal handles certificate parsing, signature validation, and connection testing.

SAML metadata exchange. For SAML, the customer's IdP exposes a metadata XML file containing their public key, entity ID, and SSO URLs. The customer uploads this to your portal; your portal generates the corresponding SP metadata for them to register at the IdP. Bidirectional metadata exchange completes the trust establishment.

OIDC discovery. For OIDC, the customer pastes their IdP's .well-known/openid-configuration URL. Your portal auto-fetches the discovery document and extracts the necessary endpoints and keys. Faster than SAML; no XML.

Connection test. Before activating the connection in production, the customer's admin signs in via the SSO flow as a test. Verifies the assertion arrives, attributes map correctly, and the user record is created.

Phase 3, Attribute mapping and JIT provisioning (10 days)

The IdP sends an assertion; your application creates a user record. The mapping in between is where most onboarding bugs surface, the customer's IdP claim names rarely match your schema verbatim, group membership semantics differ across IdPs, and the edge cases (missing attributes, existing accounts, multi-group users) need explicit handling. Phase 3 is where the integration moves from "the connection works" to "the integration is correct."

Attribute mapping. The IdP's claim names may not match your schema. The customer's Okta sends email_address; your application expects email. The CIAM provides per-Org mapping configuration so the customer's admin can correct the names without engineering involvement.

JIT provisioning. First-login auto-creates the user record from the assertion attributes. Most B2B SaaS uses JIT for first-login plus SCIM for ongoing lifecycle (Phase 4). JIT alone is sufficient for early adopters; B2B SaaS at scale needs SCIM too.

Group / role mapping. If the customer's IdP sends group claims, map them to your application's role model. Common pattern: groups ending in -admin map to admin role; groups ending in -viewer map to viewer; default role for unmapped users.

Edge cases. What happens when the assertion is missing a required attribute? When the user already has a non-SSO account on your service? When the same user is in multiple groups with different roles? Document the resolution rules; the CIAM's per-Org config should expose them.

Phase 4, SCIM provisioning if required (15 days)

JIT covers first-login; it does not cover deprovisioning. For customers above ~1000 seats, SCIM is required as a hard contract dependency, manual user management at that scale is unacceptable to the customer's security team. Phase 4 stands up the SCIM endpoint, validates it against the customer's IdP, and confirms the deprovisioning round-trip end-to-end. Skip this phase only if the customer is below the SCIM threshold and explicitly opts out.

SCIM endpoint. The CIAM exposes a SCIM 2.0 endpoint (most do; verify yours). The customer's IdP pushes user creates, updates, and deletes via REST.

Group sync. Group memberships flow through SCIM Groups endpoints. Map the customer's IdP groups to your role model, typically the same mapping logic used for JIT.

Initial sync. A 10,000-seat customer's first SCIM sync creates 10,000 user records in rapid succession. Rate limit, batch, or queue to avoid hammering your application database.

Deprovisioning verification. When a test user is removed in the IdP, confirm SCIM propagates the removal: user marked inactive in your application, sessions terminated, API tokens revoked. This is the deprovisioning guarantee that justifies SCIM.

Phase 5, Production cutover and customer handoff (20 days)

With the connection tested and provisioning verified, hand off to the customer for production rollout. The cutover is structured as a staged rollout, a small pilot first, broader rollout after a two-week observation window, with the customer's IT team owning operations after handoff. The 20-day duration accounts for the pilot, the observation period, the full rollout, and the post-rollout audit that confirms nothing latent surfaces.

Pilot population. Customer rolls out SSO to a small initial group (10–50 users). Monitor for issues: assertion validation failures, attribute mapping bugs, group sync surprises. Two-week observation window before broader rollout.

Full rollout. Customer enables SSO for the entire user base. Existing users with passwords transition to SSO at next login. Document the migration UX (one-time consent screen, account merging if applicable).

Post-rollout audit. Two weeks after full rollout, review the audit logs together: how many SSO logins, how many SCIM events, any unusual patterns, any false-positive deprovisioning. This is the moment to surface and fix any latent issues.

Customer documentation. Deliver a customer-facing runbook: how to add new users via SCIM, how to update SSO configuration, how to query audit logs, who to contact if SSO breaks. The customer's IT team owns the integration after handoff.

Anti-patterns to avoid

• Per-customer engineering for each onboarding. Doesn't scale. The CIAM's self-service portal is the only sustainable path beyond the first few customers.
• Skipping the test connection before production. Testing in production catches the most embarrassing bugs (broken assertions, wrong cert) at the worst possible moment. Test on a controlled population first.
• JIT without SCIM for 1000+ seat customers. Manual deprovisioning at scale fails; SCIM is the deprovisioning guarantee that customer security teams require.
• Treating SAML and OIDC as interchangeable. Customer procurement may specifically require one; the engineering team should ship both, but the customer's choice is theirs.
• Logging the customer's IdP signing key in cleartext. Standard mistake; the certificate goes in the audit log; the private key never does.

What success looks like at day 60

• One enterprise customer fully onboarded with SAML or OIDC SSO and (if applicable) SCIM.
• Self-service admin portal the customer's IT admin can use without your engineering team.
• JIT provisioning for first-login plus SCIM for ongoing lifecycle.
• Per-Org audit log access so the customer's security team can query their own data.
• Customer runbook documenting day-2 operations for their IT team.

For broader B2B SaaS context, see the B2B SaaS identity guide, the Enterprise SSO guide, and the SCIM provisioning guide.