SCIM Protocol: What It Is and Why It Matters

Last updated: June 2026

SCIM (System for Cross-domain Identity Management) is an open standard for automatically provisioning and deprovisioning user accounts across applications. It defines a REST/JSON API so that when someone joins, changes role, or leaves your company, your identity provider (Okta, Microsoft Entra ID, Google Workspace, and so on) can create, update, and disable their accounts in every connected app without anyone touching a spreadsheet. In short: SSO gets a user in, SCIM decides what accounts they have, and just as importantly, removes them on the way out.

Key takeaways

• SCIM automates the user lifecycle (create, update, deactivate) across apps using a standard REST API.
• SCIM 2.0 is defined by RFC 7643 (schema) and RFC 7644 (protocol), with standard /Users and /Groups endpoints.
• SCIM handles provisioning; SAML/OIDC handle authentication. They are complementary, not competing.
• Keycloak does not ship SCIM out of the box, so you add it with an extension or a managed provider.

What is SCIM?

SCIM is a standard that lets an identity provider (the “source of truth” for who works at your company) push identity data into the applications those people use. Instead of every SaaS vendor inventing its own user-sync API, SCIM gives them all one common contract: the same endpoints, the same JSON shape, the same operations.

The problem it solves is old and expensive. Without automated provisioning, onboarding a new hire means an admin manually creating accounts in a dozen tools, and offboarding means remembering to disable all of them. The accounts that get forgotten on offboarding (orphaned accounts with live credentials) are one of the most common audit findings and a real security risk. SCIM turns that manual, error-prone process into an automatic one driven by your directory.

The evolution of SCIM

SCIM 1.0 and 1.1 appeared around 2011 to standardize cloud user management. The version everyone uses today is SCIM 2.0, published by the IETF in 2015 across three RFCs:

• RFC 7642: definitions, concepts, and requirements (the “why”).
• RFC 7643: the core schema: the User, Group, and EnterpriseUser resource types.
• RFC 7644: the protocol itself: the REST API, endpoints, filtering, and the bulk/PATCH semantics.

When a vendor says “we support SCIM,” they almost always mean SCIM 2.0 per RFC 7643/7644.

Why SCIM matters today

The average company now runs dozens to hundreds of SaaS apps. Managing identities by hand across all of them does not scale, and it does not pass an audit. SCIM matters because it delivers three things at once: security (deprovisioning happens automatically, closing the orphaned-account gap), efficiency (no manual account churn for IT), and compliance (a consistent, reviewable record of who has access to what).

How SCIM works

A SCIM setup has two roles:

• The identity provider / SCIM client (e.g., Entra ID, Okta), the system that knows the authoritative list of users and sends changes.
• The service provider / SCIM server (the application being provisioned into), the system that exposes SCIM endpoints and applies those changes.

The service provider publishes a base URL and a bearer token. The identity provider then calls standard endpoints over HTTPS:

The operations map to HTTP verbs you already know: POST to create a user, GET (with a filter such as userName eq "[email protected]") to find one, PUT to replace a record, PATCH to make a partial change (for example, flipping active to false on offboarding), and DELETE to remove it. A minimal SCIM user resource looks like this:

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "[email protected]",
  "name": { "givenName": "Jane", "familyName": "Doe" },
  "emails": [{ "value": "[email protected]", "primary": true }],
  "active": true
}

That predictable shape is the whole point: any compliant client can talk to any compliant server.

SCIM and Keycloak

Here is the part most articles get wrong, so let’s be precise: Keycloak does not include a built-in SCIM server or client, even in the 26.x line. Out of the box, Keycloak speaks OpenID Connect and SAML for authentication, and it can federate users from LDAP, but it does not expose SCIM /Users and /Groups endpoints, and it cannot act as a SCIM client to push users into other apps.

To get SCIM with Keycloak, you have three realistic options:

1. A community extension. Open-source plugins add SCIM server or client capability to Keycloak. They work, but you own the build, the upgrades across Keycloak versions, and the security patching.
2. A custom provisioning bridge. You write a service that translates between Keycloak’s Admin API / event SPI and SCIM. Maximum control, maximum maintenance.
3. A managed provider. A hosted Keycloak that ships SCIM as a supported feature, so you get standards-compliant /Users and /Groups endpoints without maintaining an extension yourself.

If you want the managed path, Skycloak provides SCIM 2.0 provisioning as a built-in feature on top of managed Keycloak. See the walkthrough on using SCIM 2.0 with Skycloak-managed Keycloak. When you are wiring up a provider and need to confirm your endpoints behave, the free SCIM Endpoint Tester lets you send live Users/Groups requests and inspect the responses.

Implementation tips

• Use email or a stable unique ID as userName. Mutable usernames cause duplicate accounts when someone changes their name.
• Deactivate, don’t delete. Most identity providers send a PATCH setting active: false rather than a hard DELETE, which preserves audit history. Make sure your downstream behavior matches.
• Map groups deliberately. Decide up front whether SCIM groups drive roles in the target app, or whether roles are managed separately.

Security considerations

The SCIM endpoint can create and disable accounts, so treat its bearer token like a master key: scope it narrowly, rotate it, and serve SCIM only over TLS. Log every provisioning event, since it is some of the highest-value data in an audit trail.

SCIM vs SAML vs LDAP

These three get confused constantly because they all touch “identity.” They do different jobs:

• SCIM vs SAML: SAML logs a user in; SCIM makes sure the account that user logs into already exists and has the right state. A mature setup uses both: SAML/OIDC for SSO, SCIM for lifecycle.
• SCIM vs LDAP: LDAP is a directory-access protocol designed for an internal network; SCIM is a REST/JSON provisioning standard designed to cross organizational boundaries between SaaS vendors. SCIM is the modern answer to “how do two companies’ systems sync users over the public internet.”

Common challenges and how to handle them

• Synchronization drift. If a change is made directly in the target app instead of the identity provider, the two fall out of sync. Fix: make the identity provider the single source of truth and disable manual edits downstream.
• Inconsistent vendor support. Not every “SCIM-compliant” app implements the same attributes or PATCH correctly. Test against the real endpoint before you trust it in production.
• Attribute mapping mismatches. Different apps expect different fields. Map your directory attributes to SCIM attributes explicitly rather than assuming defaults.

Best practices for implementing SCIM

1. Make one system authoritative. SCIM only works cleanly when there is a single source of truth driving every change.
2. Provision by group, not by hand. Drive access from directory groups so onboarding and role changes are automatic.
3. Verify deprovisioning. Test that disabling a user in the directory actually disables them everywhere. This is the security payoff and the part teams forget to check.
4. Test endpoints continuously. Use a SCIM tester when you onboard each new application so a broken integration surfaces immediately, not during an incident.
5. Keep the audit trail. Log provisioning events and retain them in line with your compliance requirements.

Frequently asked questions

Is SCIM an authentication protocol?
No. SCIM provisions and manages accounts; it does not log users in. Authentication is handled by SAML or OpenID Connect. The two are designed to work together.

Does Keycloak support SCIM natively?
No. As of Keycloak 26.x there is no built-in SCIM server or client. You need a community extension, a custom bridge, or a managed Keycloak provider that offers SCIM as a feature.

What is the difference between SCIM and just using an API?
A proprietary API works only with the one vendor that built it. SCIM is a standard API, so a single integration in your identity provider works across every compliant application.

What version of SCIM should I use?
SCIM 2.0 (RFC 7643/7644). It is the version supported by every major identity provider and is what vendors mean when they say “SCIM.”

Does SCIM replace SSO?
No, it complements it. SSO authenticates the user at login; SCIM keeps the underlying accounts and their access correct over time.

Conclusion

SCIM is the quiet workhorse of modern identity: it keeps accounts accurate across every app a person touches, and it removes them automatically when they leave. Pair it with SSO and you have the full picture: authentication handled by SAML/OIDC, the account lifecycle handled by SCIM.

Keycloak gives you world-class authentication but leaves SCIM to you. If you would rather not build and maintain that yourself, explore Skycloak’s managed SCIM provisioning, read the hands-on Keycloak SCIM guide, and validate your setup with the free SCIM Endpoint Tester. Try Skycloak free and get managed Keycloak with SCIM provisioning built in.