SCIM vs SAML: Provisioning vs Authentication, and Why You Need Both

Key takeaways

• SAML authenticates a user at the moment of login. SCIM provisions and deprovisions user accounts in the background, without the user being involved.
• Both are required for enterprise B2B SaaS: SAML handles 'can this person log in?'; SCIM handles 'should this account still exist after their employment ended?'.
• The procurement question 'do you support SCIM?' is the lifecycle question — the customer wants automated offboarding, not authentication.
• JIT (just-in-time) provisioning from SAML attributes is the cheap-and-cheerful lifecycle. SCIM Directory Sync is the production answer for accounts and groups at scale.

The split

The two protocols solve different halves of the enterprise integration:

	SAML	SCIM
What it does	Authenticates a user at login	Provisions and deprovisions user accounts
When it runs	Synchronous, at every login	Asynchronous, on directory changes
Who initiates	The user (clicks 'sign in')	The IdP (pushes changes to the app)
Format	XML signed assertions	JSON over REST
Standard year	2005 (OASIS)	2015 (RFC 7642-7644)
B2B procurement weight	Heavy (the security questionnaire)	Heavy (the lifecycle / offboarding section)

A typical enterprise B2B SaaS deployment uses SAML or OIDC for the authentication flow at login and SCIM for the lifecycle of accounts in the background. The customer's IT admin configures both, often in the same self-service IdP setup screen.

What SCIM actually does

SCIM is a REST API specification. The IdP makes HTTP calls to the application's SCIM endpoint to manage the application's users:

• POST /Users — create a new user account (the IdP added someone to the group that grants access to this app).
• PUT /Users/{id} — update an existing user's attributes (email changed, name changed, manager changed).
• PATCH /Users/{id} with active: false — deactivate the user (the most operationally important operation; this is offboarding).
• DELETE /Users/{id} — delete the user (used less commonly; most apps deactivate rather than delete for audit reasons).
• POST /Groups, PUT /Groups/{id}, etc. — manage group memberships (used for role assignment in many apps).

The application implements the SCIM endpoint; the IdP (Okta, Microsoft Entra, Google Workspace, OneLogin, JumpCloud) drives the requests. The protocol is straightforward — the engineering work is in attribute mapping, idempotency, conflict resolution, and matching the application's user model to SCIM's schema.

Why SAML alone leaves the deprovisioning gap

A SAML-only deployment works like this:

• Employee Alice joins the customer; admin grants her access to your app via the IdP.
• Alice logs into your app via SAML; you JIT-provision her account on first login.
• Alice uses the app for two years.
• Alice leaves the company; admin revokes her access in the IdP.
• Alice's account in your app... still exists.

Without SCIM, the application has no way of knowing Alice left. She can no longer log in via SAML (the IdP won't authenticate her), but her account, her data, her permissions, and any active session cookies persist in your app indefinitely. The customer's IT compliance posture says "all access revoked on offboarding"; your app silently failed that requirement.

SCIM Directory Sync fixes this: when the admin revokes Alice's access in the IdP, the IdP fires a SCIM PATCH /Users/alice-id with active: false to your app, and your app deactivates the account, terminates sessions, and (per policy) archives or deletes the data.

For enterprise customers with hundreds of SaaS apps, SCIM is the only mechanism that scales offboarding. Manual deprovisioning is a compliance failure waiting to happen.

JIT provisioning: the lightweight alternative for the create side

Just-in-time (JIT) provisioning creates the user account on first SAML login by reading the assertion's attributes (email, first name, last name, groups). It's the cheap-and-cheerful lifecycle:

• ✅ Solves first-login onboarding cleanly without SCIM infrastructure.
• ✅ Works for any IdP that emits standard attributes.
• ❌ Doesn't handle deprovisioning at all.
• ❌ Doesn't handle attribute updates after first login (Alice's department changed, but JIT only runs once).
• ❌ Doesn't handle pre-provisioning (admin wants to add an account before the user's first login).

JIT plus SCIM is the production pattern. JIT covers the convenience of first login; SCIM covers the ongoing lifecycle. Many CIAM platforms ship both as out-of-the-box capabilities.

The procurement question, explicitly

When an enterprise customer's security questionnaire asks "do you support SCIM?", the question is about:

1. Automated provisioning: can the customer's IdP push user records to your app without anyone clicking in your admin UI?
2. Automated deprovisioning: when an employee leaves, will their account in your app be deactivated automatically, within hours not days?
3. Group sync: can role assignments in the IdP propagate to permissions in your app?
4. Attribute updates: when an employee changes departments, does the change reflect in your app?

The answer they want: yes, via standard SCIM 2.0 (RFC 7644), with attribute mapping documented, with deactivation propagating within minutes, with group / role sync supported. Anything less is a finding on the customer side and, often, a deal-blocker.

Implementation guidance

1. Ship SAML or OIDC for authentication and SCIM for lifecycle, both per-Organization. Either alone is insufficient for enterprise B2B.
2. Use a CIAM that handles SCIM as a primitive. Building a compliant SCIM endpoint is real engineering work; the major B2B-focused CIAMs (WorkOS, Auth0, Frontegg, Okta, MojoAuth) ship it as a feature.
3. Default to JIT + SCIM: JIT for first-login onboarding convenience, SCIM for the ongoing lifecycle.
4. Test against the major IdPs: Okta, Microsoft Entra, Google Workspace, OneLogin, JumpCloud. Each has SCIM client quirks; testing once per major IdP catches the integration-edge bugs.
5. Document your SCIM support explicitly in customer-facing materials: which version (2.0), which attributes are mapped, what the deactivation latency is. The detail wins B2B security reviews.
6. Log everything on the SCIM endpoint — provisioning events are audit-relevant for the customer.