Glossary Term

SCIM Provisioning

glossary scim provisioning featured

SCIM provisioning is the automated creation, updating, and removal of user accounts in software applications using SCIM, the System for Cross-domain Identity Management standard. An identity provider such as Okta or Microsoft Entra ID pushes each change to every connected app, so nobody has to add or remove users by hand. When an employee joins, moves teams, or leaves, their access in every app changes within minutes.

How SCIM Provisioning Works

SCIM provisioning connects two systems: a SCIM client and a SCIM service provider.

  • SCIM client. The identity provider (IdP) that holds the master list of users. Okta, Microsoft Entra ID, OneLogin, and JumpCloud all act as SCIM clients.
  • Service provider. The app that receives changes, such as Slack, Zoom, or GitHub. It exposes a SCIM API endpoint.

The flow runs in one direction, from the IdP to the app:

  1. An admin assigns a user or group to the app inside the IdP.
  2. The IdP sends an HTTPS request to the app’s SCIM endpoint, authenticated with a bearer token.
  3. The app creates the account and returns the user’s SCIM ID.
  4. Later changes (name, department, group membership) trigger update requests.
  5. Unassigning the user triggers deprovisioning.

A create request looks like this:

POST /scim/v2/Users
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "[email protected]",
  "name": { "givenName": "Priya", "familyName": "Shah" },
  "active": true
}

SCIM 2.0 Explained

SCIM 2.0 is the current version of the standard, published by the IETF in September 2015 as three RFCs:

  • RFC 7642. Concepts, definitions, and use cases.
  • RFC 7643. The core schema: the attributes that describe a User and a Group.
  • RFC 7644. The protocol: endpoints, HTTP methods, filtering, and PATCH semantics.

The standard began in 2011 as “Simple Cloud Identity Management”, backed by Salesforce, Google, Ping Identity, and Cisco. SCIM 1.0 shipped in December 2011 and 1.1 in July 2012. When the work moved to the IETF, the acronym was kept but renamed to reflect its broader scope.

SCIM 2.0 uses standard REST conventions. Resources live at /Users and /Groups, and are managed with GET, POST, PUT, PATCH, and DELETE. Discovery endpoints (/ServiceProviderConfig, /Schemas, /ResourceTypes) let the IdP learn which features the app supports. SCIM 1.1 and 2.0 are not compatible, so an IdP connector must match the version the app implements.

SCIM Deprovisioning

Deprovisioning is the main reason organizations adopt SCIM. When a user is unassigned or disabled in the IdP, the app deactivates the account automatically.

Most IdPs deactivate rather than delete. They send a PATCH that sets active to false:

PATCH /scim/v2/Users/2819c223
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [{ "op": "replace", "path": "active", "value": false }]
}

A deactivated account cannot log in, but its data and history survive. Files, messages, and records stay attributed to the person, which keeps the audit log intact. A DELETE request removes the account entirely and is usually reserved for data-retention cleanup.

Without SCIM, offboarding depends on someone remembering every app a leaver used. Orphaned accounts, left active after someone departs, are a standard finding in access reviews and SOC 2 audits.

SCIM vs SAML

SAML controls how a user logs in. SCIM controls whether the account exists at all. The two are complementary, and most enterprise apps support both.

SAML SCIM
Purpose Authentication (single sign-on) Account lifecycle management
Question answered Is this person who they claim to be? Should this account exist, with what attributes?
When it runs At each login Whenever the IdP record changes
Format Signed XML assertion JSON over a REST API
Standard OASIS SAML 2.0 (2005) IETF RFC 7643 and 7644 (2015)

SAML alone leaves a gap. Some apps use just-in-time (JIT) provisioning, creating an account on a user’s first SAML login. JIT never removes accounts, and a disabled SSO login does not revoke API tokens or active sessions. SCIM closes that gap. The Slack single sign-on setup guide shows the two configured together in practice.

Common SCIM Provisioning Issues

  • Plan gating. Many SaaS vendors restrict SCIM to enterprise tiers, so smaller teams often go without it.
  • Attribute mapping errors. The IdP’s department field may map to nothing in the app, or to the wrong field. Test with one user before assigning groups.
  • Groups do not equal roles. SCIM syncs group membership, but the app decides what each group can do. The permissions still come from the app’s role-based access control model.
  • One-way sync. Changes made directly in the app are overwritten or ignored. The IdP must be the single source of truth.
  • Token expiry. An expired bearer token silently stops provisioning. Monitor the IdP’s provisioning logs for failed requests.

Frequently Asked Questions

What is SCIM?

SCIM stands for System for Cross-domain Identity Management. It is an open standard, defined in IETF RFCs 7643 and 7644, for exchanging user identity data between an identity provider and applications over a REST API. It lets one central directory create, update, and remove accounts in many apps automatically. Most major SaaS products and all major identity providers support it.

What is the difference between SCIM and SAML?

SAML handles authentication: it verifies a user’s identity each time they log in through single sign-on. SCIM handles provisioning: it creates, updates, and deactivates the account itself. SAML without SCIM means users log in centrally but accounts must still be removed by hand. Most organizations deploy both together.

What is automated user provisioning?

Automated user provisioning is the process of creating and managing user accounts in applications without manual admin work, triggered by changes in a central directory. SCIM is the most widely used standard for it. When HR adds a new hire to the directory, their accounts in every assigned app are created before their first day.

What happens when a user is deprovisioned with SCIM?

The identity provider sends a request telling the app to deactivate the account, usually by setting active to false. The user can no longer log in, but their data and activity history remain. Some apps also transfer ownership of the user’s content to an admin. Full deletion happens only if the IdP sends a DELETE request.

To control who on your team can create and edit campaign links, set up linkutm team workspaces.

Back to Glossary