Last updated: July 2026
SCIM, the System for Cross-domain Identity Management, is an open standard (RFC 7643 and RFC 7644) that automates provisioning and deprovisioning of user accounts between identity providers and applications over a REST API with a standardized user schema. Instead of writing a custom sync integration for every app, an identity provider pushes creates, updates, and deactivations to any SCIM-compliant endpoint.
It’s pronounced “skim,” and it exists because the alternative, an admin manually creating and deleting accounts in every tool your company uses, doesn’t scale and doesn’t pass audits.
Key takeaways
- SCIM automates the full user lifecycle (create, update, deactivate) across applications through one standard REST/JSON API.
- SCIM 2.0 is defined by RFC 7643 (the schema) and RFC 7644 (the protocol), with standard
/Usersand/Groupsendpoints.- SCIM provisions accounts. SAML and OIDC authenticate users. Mature identity stacks run both together.
- Keycloak historically needed extensions for SCIM. Recent releases add a native, experimental SCIM 2.0 server behind a feature flag.
What problem does SCIM solve?
SCIM solves the account lifecycle problem. Someone joins your company, changes teams, or leaves, and every application they touch needs to reflect that change. Without automation, each of those events turns into tickets, spreadsheets, and manual clicks in a dozen admin consoles. SCIM replaces all of that with one standard API driven by your directory.
The scale of the problem keeps growing. Okta’s Businesses at Work report has tracked the average company’s app portfolio at more than 90 applications for several years running (Okta, 2024). Nobody is keeping 90 apps in sync by hand. And the failure mode isn’t just wasted IT time.
The real risk is offboarding. When someone leaves and their accounts stay active, you get orphaned accounts: live credentials attached to a person who no longer works for you. These show up constantly in security audits, and they’re exactly the kind of access an attacker loves to find. SCIM closes that gap by deactivating accounts everywhere the moment the directory says someone is gone.
There’s also an integration economics problem. Before SCIM, every identity provider and every application pair needed its own proprietary connector. Ten identity providers and a hundred apps means a thousand potential integrations. SCIM collapses that to one contract: build a compliant endpoint once, and any compliant identity provider can provision into it.
Where SCIM came from
SCIM 1.0 appeared in 2011 under the name Simple Cloud Identity Management, driven by a working group you can still find at scim.cloud. The version everyone uses today is SCIM 2.0, standardized by the IETF in September 2015 across three RFCs: RFC 7642 for concepts and requirements, RFC 7643 for the core schema, and RFC 7644 for the protocol itself. When a vendor says “we support SCIM,” they mean SCIM 2.0.
How does SCIM 2.0 work?
SCIM defines two roles and a REST API between them. The application being provisioned acts as the SCIM service provider: it exposes HTTPS endpoints and applies changes. Your identity provider acts as the SCIM client: it holds the authoritative user list and pushes changes to those endpoints as directory data changes.
Yes, the naming is backwards from what you’d expect. In SCIM terms, the identity provider is the “client” and the app is the “service provider,” because the app is the one serving the API. Keep that straight and vendor docs get much easier to read.
Resources: Users and Groups
SCIM models identity data as resources with a defined schema. The core spec ships two, plus a standard extension for workplace attributes.
| Resource | Endpoint | What it represents |
|---|---|---|
User |
/Users |
A person’s account: identifiers, profile attributes, and active status |
Group |
/Groups |
A named collection of users, typically mapped to roles or access levels |
EnterpriseUser (extension) |
/Users |
Extra workplace fields: employee number, department, manager, cost center |
The core user schema
RFC 7643 defines the attributes a User resource carries. A handful do most of the work in real deployments.
| Attribute | Purpose |
|---|---|
userName |
Unique login identifier, usually the work email address |
id |
Immutable identifier assigned by the service provider |
externalId |
The client’s own identifier, used to cross-reference the two systems |
name |
Structured name with givenName and familyName |
emails |
One or more addresses, each with a type and a primary flag |
active |
Boolean account status; false means the account is deactivated |
groups |
Read-only list of the user’s group memberships |
SCIM endpoints
A SCIM service provider exposes a small, predictable set of endpoints under a base URL such as https://app.example.com/scim/v2.
| Endpoint | Purpose |
|---|---|
/Users |
Create, read, search, update, and delete user resources |
/Groups |
Manage groups and their membership |
/ServiceProviderConfig |
Advertises which features the server supports: PATCH, filtering, bulk, auth schemes |
/Schemas |
Machine-readable definitions of every attribute the server understands |
/ResourceTypes |
Lists the available resource types and where they live |
/Bulk |
Optional endpoint for batching many operations into one request |
A well-behaved client checks /ServiceProviderConfig first, so it only uses features the server actually implements. That discovery step is a big part of why one integration works across many vendors.
Operations, PATCH, and filtering
The operations map onto HTTP verbs you already know.
| Request | What it does |
|---|---|
POST /Users |
Create a new user |
GET /Users/{id} |
Read one user by server-assigned ID |
GET /Users?filter=... |
Search, for example userName eq "[email protected]" |
PUT /Users/{id} |
Replace the entire user resource |
PATCH /Users/{id} |
Apply a partial change to specific attributes |
DELETE /Users/{id} |
Remove the resource entirely |
PATCH is the verb that matters most in practice, because it’s how deprovisioning usually happens. Rather than deleting an account and losing its audit history, the identity provider flips one attribute:
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{ "op": "replace", "path": "active", "value": false }
]
}Filtering matters too. Before creating a user, a client typically searches by userName or externalId to check whether the account already exists. That’s what keeps provisioning idempotent instead of duplicate-prone.
What a SCIM user looks like
Here’s a realistic SCIM 2.0 user resource, including the enterprise extension and the server-managed meta block:
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
],
"id": "2819c223-7f76-453a-919d-413861904646",
"externalId": "e9e30dba-f08f-4109-8486-d5c6a331660a",
"userName": "[email protected]",
"name": {
"givenName": "Jane",
"familyName": "Doe"
},
"displayName": "Jane Doe",
"emails": [
{ "value": "[email protected]", "type": "work", "primary": true }
],
"active": true,
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"employeeNumber": "70142",
"department": "Engineering",
"manager": { "value": "26118915-6090-4610-87e4-49d8ca9f808d" }
},
"meta": {
"resourceType": "User",
"created": "2026-07-01T09:12:03Z",
"lastModified": "2026-07-10T14:02:47Z",
"location": "https://app.example.com/scim/v2/Users/2819c223-7f76-453a-919d-413861904646"
}
}That predictable shape is the entire value proposition. Any compliant client can talk to any compliant server without either side reading the other’s API docs.
How does SCIM relate to SSO?
SCIM and SSO are the classic pairing, and they answer different questions. SSO protocols like SAML and OpenID Connect answer “is this person who they claim to be?” at login time. SCIM answers “should this person have an account here at all, and in what state?” continuously, as your directory changes.
Think about what each one can’t do alone. SSO without SCIM means accounts either get created by hand or spring into existence at first login, and nothing ever cleans them up when people leave. SCIM without SSO means accounts are perfectly synchronized but everyone still juggles separate passwords. Together, the identity provider controls both the login and the lifecycle.
A typical enterprise integration checklist reflects this: the app supports SAML or OIDC for authentication, plus SCIM for provisioning. If you’re building the authentication half, our SSO implementation guide for developers covers the SAML and OIDC side in depth.
How do identity providers use SCIM in practice?
The big identity providers all implement SCIM the same basic way: you give them a base URL and a credential, and they push changes on their own schedule. The details differ slightly per vendor, but the shape is consistent, which is the whole point of a standard.
In Microsoft Entra ID, an admin adds the application, opens its provisioning settings, and enters the app’s SCIM tenant URL and secret token. Entra then runs provisioning cycles on a fixed interval, roughly every 40 minutes, comparing assigned users against the app and pushing creates, updates, and deactivations (Microsoft Learn, 2026).
Okta’s lifecycle management works the same way but pushes changes as they happen rather than on a cycle. Assign a user to the app and Okta sends the POST /Users within moments; suspend them and the PATCH follows (Okta developer docs, 2026). Both platforms also let admins map directory attributes to SCIM attributes and scope provisioning to specific groups.
One convention worth knowing: nearly all identity providers deactivate rather than delete. Offboarding sends active: false, not DELETE, which preserves the account’s audit trail. Make sure whatever sits on the receiving end treats a deactivated account as fully locked out.
Does Keycloak support SCIM?
Yes, with an important nuance. For most of its history, Keycloak shipped no SCIM support at all: it spoke OIDC and SAML for authentication and left provisioning to community extensions or custom code. That has changed. Recent Keycloak releases include a native SCIM 2.0 server implementation as an experimental feature, enabled behind a feature flag and aimed first at compatibility with identity providers like Entra ID.
Experimental is the operative word. The native implementation is a preview: it covers core user and group operations but not yet the full protocol surface, and experimental features can change between releases. Before you build on it, check the official Keycloak release notes and the supported features list for its current status and how to enable it.
So what do teams actually run in production today? Three options, in increasing order of convenience:
- The native experimental feature, if you’re comfortable tracking an evolving preview across upgrades.
- A mature community extension, which adds production-grade SCIM server capability but makes you the owner of builds, upgrades, and security patching.
- A managed provider that ships SCIM as a supported feature. Skycloak includes SCIM 2.0 provisioning on managed Keycloak, so you get standards-compliant
/Usersand/Groupsendpoints without maintaining the plumbing.
This article is the conceptual reference for SCIM. For the hands-on setup, the companion guide Using SCIM 2.0 with Skycloak-managed Keycloak walks through enabling the SCIM server, choosing an authentication mode, and exercising real Users and Groups calls. And whichever route you take, the free SCIM Endpoint Tester lets you fire live requests at your endpoint from the browser and inspect exactly what comes back.
One related distinction trips people up: SCIM is not how Keycloak talks to your on-premises directory. If your source of truth is Active Directory or OpenLDAP, Keycloak federates it directly through user federation, which we cover in the Keycloak LDAP integration guide. SCIM is for provisioning across organizational boundaries, typically between a cloud identity provider and SaaS applications.
SCIM vs just-in-time (JIT) provisioning
JIT provisioning is the main alternative you’ll hear about, and it’s much simpler: the application creates the account automatically at the user’s first SSO login, using attributes from the SAML assertion or OIDC token. No endpoint, no token, no sync engine. So why doesn’t everyone just use JIT?
| SCIM provisioning | JIT provisioning | |
|---|---|---|
| When the account is created | Ahead of time, when the user is assigned in the identity provider | At the user’s first SSO login |
| How updates flow | Pushed continuously as directory data changes | Refreshed only when the user logs in again |
| Deprovisioning | Automatic: the identity provider deactivates the account | None; the account lingers until someone removes it manually |
| Group and role sync | Yes, via /Groups |
Limited to whatever attributes fit in the login assertion |
| Access before first login | Yes: licenses, mailboxes, and shares can be pre-assigned | No |
| Setup effort | Higher: endpoint, credential, attribute mappings | Lower: often just attribute mapping in the SSO config |
The gap that matters is the deprovisioning row. JIT can create accounts but has no mechanism to remove them, because a departed employee simply never logs in again while their account sits there, active. That’s the orphaned-account problem all over again.
In practice this isn’t either/or. Plenty of teams start with JIT to get moving, then add SCIM once offboarding automation and group sync become requirements. If compliance is in the picture, SCIM tends to stop being optional.
Security considerations for SCIM endpoints
A SCIM endpoint can create, modify, and disable accounts, which makes it one of the most sensitive APIs you’ll ever expose. RFC 7644 deliberately leaves authentication schemes flexible, and in practice almost every deployment uses a long-lived bearer token configured in the identity provider. Treat that token accordingly.
- Serve SCIM over TLS only. The token rides in a header on every request; plaintext HTTP would hand it to anyone on the path.
- Scope the credential to least privilege. The token should manage users and groups, nothing else. If your implementation supports OAuth client credentials with narrow scopes, prefer that over a static secret.
- Rotate tokens on a schedule, and immediately when staff with access to them leave. A leaked SCIM token is an account-creation factory for an attacker.
- Log every provisioning event. Who was created, updated, or deactivated, when, and by which client. This is some of the highest-value audit data you can collect.
- Restrict and rate-limit access where you can: IP allowlists for your identity provider’s ranges, and throttling to blunt brute-force or scraping attempts against
/Users.
It’s also worth testing failure behavior, not just the happy path. What happens when the same user is created twice? When a PATCH arrives for an ID that doesn’t exist? Compliant, boring answers to those questions are what separate a solid SCIM endpoint from a liability.
Frequently asked questions
What does SCIM stand for?
SCIM stands for System for Cross-domain Identity Management. The 1.0 version from 2011 was called Simple Cloud Identity Management; the name changed when the IETF standardized SCIM 2.0 in 2015 as RFC 7643 and RFC 7644. It’s pronounced “skim.”
What is the difference between SCIM and SSO?
SSO authenticates users at login time using protocols like SAML or OpenID Connect. SCIM provisions the accounts those users log into: creating them, keeping attributes current, and deactivating them at offboarding. They’re complementary, and enterprise-grade applications typically support both together.
Does Keycloak support SCIM?
Yes, with caveats. Recent Keycloak releases ship a native SCIM 2.0 server as an experimental, flag-gated feature; check the official release notes for its current status. Production deployments today commonly use a mature extension or a managed Keycloak provider that offers SCIM as a supported feature.
What is a SCIM endpoint?
A SCIM endpoint is the HTTPS base URL an application exposes for provisioning, such as https://app.example.com/scim/v2, with standard paths like /Users, /Groups, and /ServiceProviderConfig beneath it. You paste that URL and a bearer token into your identity provider’s provisioning settings to connect the two.
Is SCIM push or pull?
Push, in practice. The identity provider acts as the SCIM client and pushes creates, updates, and deactivations to the application’s endpoint. The protocol itself is plain request-response REST, and some providers also read back from the endpoint to reconcile state, but the flow of truth runs from directory to app.
SCIM in one sentence
If SSO is the front door, SCIM is the facilities team: it makes sure the right people have keys before they arrive and collects those keys the day they leave. Pair SAML or OIDC for authentication with SCIM for lifecycle, and the identity provider becomes the single place where access is granted and revoked.
If Keycloak is your identity layer, you now know the landscape: a promising native experimental feature, extensions you can run yourself, or a managed platform that treats SCIM as a first-class capability. Skycloak’s managed Keycloak includes SCIM provisioning out of the box, and plans start free if you want to try it against a real endpoint this afternoon.