SCIM 2.0 is the cross-domain user provisioning protocol — it's how your IdP keeps SaaS user accounts in sync.
TL;DR
SCIM 2.0 (RFC 7643 + RFC 7644, 2015) defines a REST + JSON protocol for managing users and groups across domains. The IdP is the SCIM client; the SaaS application is the SCIM server. When you hire someone in Workday → Entra creates the user → SCIM provisions accounts in Slack, GitHub, Salesforce, etc. When they leave → SCIM disables those accounts.
Published by
IETF
Who uses it
Every modern IdP — Okta, Entra, Google, JumpCloud, OneLogin, Auth0. Every SaaS product that supports enterprise SSO almost always also supports SCIM provisioning (often as a higher-tier paid feature).
Reviewed
2026-05-22
When to use
Any time you need to keep user accounts in sync across two systems where one is the authoritative source. JML automation. Group / role membership sync. Cross-domain license management.
When not to use
Synchronous, low-latency provisioning (SCIM is REST + polling). Bidirectional sync (SCIM is one-way IdP → app). Complex transformation logic mid-stream (do that in the IdP's SCIM-client mapping layer, not in the SCIM call itself).
SCIM 2.0 defines a small REST surface. In practice, almost all traffic hits these:
POST /Users # Create a user
GET /Users/{id} # Read a user
PUT /Users/{id} # Replace a user (full update)
PATCH /Users/{id} # Modify a user (partial update)
DELETE /Users/{id} # Delete a user (often soft via active=false)
GET /Users?filter=... # Search (e.g. by userName)
# Same shape for /GroupsA minimum-conformant User payload:
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "[email protected]",
"name": {
"givenName": "Jane",
"familyName": "Doe"
},
"emails": [
{ "value": "[email protected]", "primary": true, "type": "work" }
],
"active": true
}Almost every workforce-IdP SCIM integration uses the enterprise extension for manager / department / employee number:
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
],
"userName": "[email protected]",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"department": "Engineering",
"employeeNumber": "E-12345",
"manager": { "value": "mgr-123", "displayName": "John Manager" }
}
}The recurring debugging surface for SCIM integrations:
If you're building SCIM into a SaaS product:
What is SCIM?
SCIM (System for Cross-domain Identity Management) is an open standard for automating user provisioning — creating, updating, and deactivating user accounts across systems via a common REST + JSON API. When HR or an IdP adds, changes, or offboards a user, SCIM pushes that change to every connected app so accounts stay in sync without manual work. It is the protocol that powers joiner/mover/leaver (JML) automation; SCIM 2.0 (RFC 7643/7644) is the current version.
Is SCIM 2.0 the same as SCIM 1.0?
No. SCIM 1.0 was a different draft from 2011 that never reached IETF standardization. SCIM 2.0 is the published RFC-based standard. Anyone shipping SCIM today means SCIM 2.0.
Can SCIM do real-time provisioning?
It can in principle — SCIM is just HTTP REST. In practice, most IdP-side SCIM clients poll on a 5-15 minute interval rather than push. Some IdPs (Okta, Entra) do near-real-time on lifecycle events.
How does SCIM handle group membership sync?
Two equivalent patterns: managing members from the User side (`groups` attribute in the User resource) or from the Group side (`members` attribute in the Group resource). Pick one consistently — mixing both creates merge conflicts.
We implement SCIM 2.0 integrations across regulated enterprises — workforce SSO, B2B SaaS federation, customer identity. Same-day reply.