SCIM (System for Cross-domain Identity Management)

What is SCIM?

SCIM — System for Cross-domain Identity Management — is an open standard for automating the exchange of user identity information between systems. In plain terms: it's how Okta, Microsoft Entra ID, JumpCloud, or your HRIS tells Slack, GitHub, Zoom, and dozens of other apps that "Alice joined Acme today, here's her email and her groups," and later "Alice left Acme yesterday — disable her account now."

SSO gets the user in the door. SCIM makes sure the door — the account — exists in the first place, and gets locked the moment it shouldn't.

How SCIM works

SCIM 2.0 is a RESTful JSON API. The identity source (usually the IdP, sometimes the HRIS) acts as a SCIM client, and the downstream app acts as a SCIM server exposing endpoints like:

• GET /scim/v2/Users — list users
• POST /scim/v2/Users — create a user
• PATCH /scim/v2/Users/{id} — update attributes or group memberships
• DELETE /scim/v2/Users/{id} — deactivate / delete

The two core resource types are User and Group. The User schema includes standard attributes (userName, emails, active, title, manager) and supports extensions for enterprise attributes or app-specific fields.

A typical lifecycle looks like:

1. HR adds Alice to Workday with start date and department.
2. The IdP imports Alice from Workday and assigns her to app groups based on role.
3. The IdP issues a SCIM POST /Users to Slack creating her account, and PATCH /Groups to add her to the right channels.
4. When Alice changes role, the IdP PATCHes her group memberships.
5. When Alice leaves, the IdP issues PATCH active=false (or DELETE) and her downstream sessions are killed.

When buyers care about SCIM

You need SCIM when:

• You have more than ~10 SaaS apps and onboarding involves manual account creation.
• Departing employees are leaving active accounts behind (huge audit and security risk).
• You're preparing for SOC 2, ISO 27001, or HITRUST — auditors will ask for evidence of automated deprovisioning.
• You're running Joiner / Mover / Leaver automation from HR-driven sources.
• You're a SaaS vendor whose enterprise buyers are asking how they wire your app into their IdP.

SCIM vs directory sync vs JIT

• SCIM — push-based, near-real-time, standardized. The IdP tells the app what changed.
• Directory sync — typically a scheduled job that pulls users from a directory (AD, LDAP) and reconciles. Older pattern.
• JIT provisioning — accounts are created the first time the user signs in via SSO. Convenient but doesn't help with deprovisioning, which is the part that matters for security.

The strongest setup is SCIM for create/update/deprovision plus JIT as a fallback for users who haven't signed in yet.

Common pitfalls

• No SCIM = manual deprovisioning. This is the single biggest source of "ghost" accounts after layoffs.
• Half-implemented SCIM. Some vendors support Users but not Groups, or accept PATCH but ignore active=false. Test the full lifecycle before signing.
• Schema mismatches. App expects employeeNumber in one place, IdP sends it in another. Plan attribute mappings carefully.
• Rate limits. Large orgs can blow through SCIM endpoint rate limits during bulk events (acquisitions, layoffs).

FAQ

Is SCIM the same as SSO?

No. SSO authenticates users at login. SCIM manages the existence of their accounts. You want both.

Why do vendors charge extra for SCIM?

The same "SSO tax" dynamic — SCIM is often bundled in the same enterprise tier as SAML. It's controversial and worth negotiating.

What's SCIM 1.1 vs 2.0?

Different schemas and endpoints. SCIM 2.0 is the standard; 1.1 only matters if you're integrating with an older app stuck on it.