IAM building block · 3 min read
Provisioning and SCIM
Short answer
Provisioning is the creation, update and removal of user accounts and access in target systems; SCIM 2.0 (RFC 7643 and RFC 7644) standardizes it with a JSON schema for users and groups and a REST API, so an identity provider or governance system can keep SaaS apps in sync, including deactivating leavers.
Key takeaways
- Deprovisioning is the most important part: a leaver's access should end within minutes, not weeks.
- SCIM uses standard REST verbs on /Users and /Groups with a defined JSON schema and PATCH operations.
- Just-in-time provisioning at sign-in creates accounts but never removes them; pair it with SCIM or API-based cleanup.
Single sign-on controls how people get in. Provisioning controls whether their accounts should exist at all, and with what access. When provisioning is manual, accounts outlive employment, people collect permissions as they change roles, and nobody can say with confidence who has access to what.
What is the joiner, mover, leaver process?
It is the lifecycle every identity goes through: created when someone joins, changed when their role changes, removed when they leave.
| Event | Trigger | Provisioning actions |
|---|---|---|
| Joiner | HR record created | Create accounts, assign birthright groups and licenses |
| Mover | Department or role change | Add new access, remove old access (often forgotten) |
| Leaver | Termination date | Disable accounts, revoke sessions and tokens, transfer data ownership |
The HR system is usually the authoritative source for employees; a vendor management system for contractors.
How does SCIM work?
SCIM defines JSON resources for users and groups and a REST API to create, read, update, delete and search them.
Create a user:
POST /scim/v2/Users
Content-Type: application/scim+json
Authorization: Bearer <token>
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "alex@example.com",
"externalId": "E10442",
"name": { "givenName": "Alex", "familyName": "Lind" },
"emails": [{ "value": "alex@example.com", "primary": true }],
"active": true
}
Deactivate them later:
PATCH /scim/v2/Users/2819c223-7f76-453a-919d
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{ "op": "replace", "path": "active", "value": false }]
}
Other parts: GET /Users?filter=userName eq "alex@example.com" for lookups, /Groups with members, an enterprise user extension for fields like department and manager, and /ServiceProviderConfig so clients can discover what the server supports. SCIM endpoints are typically protected with an OAuth bearer token; check its scope and lifetime with the JWT Decoder if it is a JWT.
What about just-in-time provisioning?
JIT provisioning creates an account the first time a user signs in through SSO, using attributes from the assertion or ID token.
It is quick to set up and good for apps where everyone in a group should have access. Its gap is the leaver: nothing tells the application the user is gone, so accounts, API tokens and shared content remain. Pair JIT with SCIM deactivation, the app's admin API, or at least periodic reconciliation.
How do I make deprovisioning reliable?
Trigger it from the authoritative source, revoke sessions and tokens, and verify.
- HR termination triggers the identity provider or IGA system immediately, or at a scheduled time.
- The IdP account is disabled and all sessions and refresh tokens revoked.
- SCIM or connectors deactivate accounts in every connected app.
- A report lists apps that could not be updated, for manual follow-up.
- Monthly reconciliation compares app accounts with the authoritative source.
Where does provisioning meet governance?
Access requests, approvals and periodic reviews decide what should be provisioned; provisioning makes it so.
Identity governance and administration (IGA) platforms combine both. See our overview of identity management systems and the audit guide for reviews and evidence.
Questions
What is the difference between SCIM 1.1 and 2.0?
SCIM 2.0, published by the IETF in 2015 as RFC 7642, 7643 and 7644, replaced the earlier 1.1 specifications with a revised schema, PATCH semantics and better filtering. New integrations use 2.0.
Who is the SCIM client and who is the server?
The system that holds the authoritative identity data, usually the identity provider or governance platform, is the client. The target application exposes the SCIM endpoints and is the server.
Should deactivated users be deleted?
Usually deactivate first (active: false), keep the account for a retention period for audit and data ownership, then delete according to policy. Some applications only support delete.