SCIM vs SAML: What Each Protocol Actually Does

Last updated: August 2026

SAML and SCIM solve different halves of the same problem. SAML authenticates a user at login: it proves who someone is and hands the application a signed assertion so they can start a session. SCIM manages the account behind that login: it creates, updates, and deactivates user records through a REST API as your directory changes. SAML runs when someone signs in. SCIM runs whether they sign in or not.

They get compared constantly because enterprise buyers ask for both in the same sentence, usually as “do you support SSO and provisioning?” The honest answer for most products is that they support one and are quietly hoping nobody asks about the other.

Key takeaways

• SAML is an authentication protocol. SCIM is a provisioning protocol. They are not alternatives.
• SAML moves a signed XML assertion through the browser at login. SCIM moves JSON over HTTPS between servers, continuously.
• SAML alone leaves you with no way to remove access when someone leaves.
• SCIM alone leaves everyone juggling separate passwords.
• Enterprise procurement checklists almost always want both, and treat deprovisioning as a security control rather than a convenience.

SCIM vs SAML at a glance

The row that matters most is “handles offboarding.” Everything else is detail.

What SAML actually sends

SAML 2.0 is a browser-mediated protocol. When someone hits a protected page, the application redirects them to the identity provider, they authenticate there, and the identity provider sends them back carrying a signed XML document called an assertion.

That assertion is the whole payload. It says who the user is, when it was issued, how long it is valid, and usually carries a handful of attributes: email, name, group memberships. The application verifies the signature, trusts the contents, and starts a session.

<saml:Assertion IssueInstant="2026-08-04T09:14:22Z">
  <saml:Issuer>https://idp.example.com</saml:Issuer>
  <saml:Subject>
    <saml:NameID Format="...:emailAddress">dana@example.com</saml:NameID>
  </saml:Subject>
  <saml:Conditions NotBefore="2026-08-04T09:14:22Z"
                   NotOnOrAfter="2026-08-04T09:19:22Z"/>
  <saml:AttributeStatement>
    <saml:Attribute Name="department">
      <saml:AttributeValue>Engineering</saml:AttributeValue>
    </saml:Attribute>
  </saml:AttributeStatement>
</saml:Assertion>

Look at NotOnOrAfter. That assertion is valid for five minutes and describes one moment. Nothing in the SAML specification (OASIS SAML 2.0, 2005) lets the identity provider reach back out and say “actually, Dana left.”

Two things follow from that design. First, SAML only knows about a user while that user is standing in front of it. Between logins the protocol is silent. Second, the assertion is a snapshot. If someone’s department changed this morning, the application finds out the next time they sign in, and not before.

If you are implementing this half, our SSO implementation guide for developers covers the SAML and OIDC flows in depth, and the Keycloak SAML service provider guide walks through the configuration end to end.

What SCIM actually sends

SCIM is the opposite shape. There is no browser and no user in the loop. Your identity provider holds the authoritative list of people and pushes changes directly to the application’s API as they happen. The schema lives in RFC 7643 and the protocol in RFC 7644.

The traffic is ordinary REST. A new hire produces a POST /Users with a JSON body. A department change produces a PATCH. Someone leaving produces a PATCH setting active: false. Group membership flows through /Groups.

PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646
Content-Type: application/scim+json
Authorization: Bearer <token>

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

That single request is the thing SAML cannot do. It arrives without the user, it arrives the moment HR updates the directory, and it locks the account whether or not anyone ever tries to log in again.

One naming quirk worth internalizing: in SCIM the identity provider is the “client” and the application is the “service provider,” because the application is the one serving the API. That is backwards from how most people say it out loud, and it makes vendor documentation much easier to read once you know.

What breaks when you only have one

SAML without SCIM. Authentication is clean and nobody manages passwords, but account lifecycle is manual. Accounts get created by hand or spring into existence at first login, and nothing ever removes them. When someone leaves, their account sits in your application, active, until a human remembers to go delete it. These are orphaned accounts, and they are one of the most common findings in a security audit. An attacker who compromises a departed employee’s credentials walks straight in.

SCIM without SAML. Accounts are perfectly synchronized and offboarding is instant, but every user still needs a password for your application specifically. You have solved the administrative problem and left the authentication problem untouched. This combination is rare in practice, and where it exists it is usually a stepping stone rather than a destination.

Neither. Someone in IT maintains a spreadsheet. This works until roughly the fortieth employee.

Do you actually need both?

For an internal tool with a dozen users, no. Add SAML so people use their company login, and handle the handful of leavers manually.

The threshold where SCIM stops being optional is usually one of these:

• You are selling to enterprises. Procurement checklists ask for provisioning by name, and increasingly treat automated deprovisioning as a security control rather than a feature.
• You are in a compliance regime. SOC 2 and ISO 27001 auditors ask how access is revoked. “A person does it” is an answer, but it is a weak one, and it fails the moment someone forgets.
• Headcount moves fast. Contractors, seasonal staff, and reorgs generate lifecycle events far faster than anyone processes tickets.
• Access costs money. Per-seat licensing means every orphaned account is a line item.

If none of those apply yet, SAML first is a reasonable order of operations. Just know that SCIM is the harder retrofit of the two, because by the time you add it you have a pile of existing accounts to reconcile against the directory.

How the two run together

In a mature stack they interleave, and it looks like this:

1. HR marks a new hire as active in the directory.
2. The identity provider sends POST /Users to every assigned application. The account exists before the person’s first day.
3. On day one, the new hire opens the application. SAML runs, they authenticate against the identity provider, and land in an account that is already set up with the right groups.
4. Six months later they move teams. The identity provider sends a PATCH updating their groups. Their access changes without anyone logging in.
5. They leave. The identity provider sends active: false. The account locks everywhere, immediately, and the audit trail stays intact.

Notice that steps 2, 4, and 5 happen with no user present. That is the entire argument for SCIM in one sentence.

Worth knowing: nearly all identity providers deactivate rather than delete on offboarding, sending active: false instead of DELETE, which preserves the audit record. Make sure whatever sits on the receiving end treats a deactivated account as fully locked out rather than merely hidden.

SCIM vs SAML in Keycloak

Keycloak has spoken SAML since the beginning. It works as both a SAML identity provider and a SAML service provider, which is unusual and genuinely useful when you are bridging two organizations. If that distinction is fuzzy, we wrote about the difference between an SP and an IdP.

SCIM is the newer half of the story. For most of Keycloak’s history there was no SCIM support at all, and teams reached for community extensions or wrote their own sync. Recent releases add a native SCIM 2.0 server as an experimental feature behind a flag. Experimental is doing real work in that sentence: it covers core user and group operations, not the full protocol surface, and experimental features can change between releases. Check the Keycloak supported features list for current status before you build on it.

If you want SCIM as a supported feature rather than a preview, Skycloak ships SCIM 2.0 provisioning on managed Keycloak, and the hands-on setup guide covers enabling the server and exercising real calls.

One distinction that trips people up: SCIM is not how Keycloak reads your on-premises directory. If Active Directory or OpenLDAP is your source of truth, Keycloak federates it directly through user federation, covered in the Keycloak LDAP integration guide. SCIM is for provisioning across organizational boundaries, typically from a cloud identity provider into SaaS applications.

Frequently asked questions

Is SCIM a replacement for SAML?

No. They do unrelated jobs. SAML authenticates a person at login; SCIM manages their account record. Replacing one with the other leaves a real gap, either no way to remove access or no single sign-on.

Can you use SCIM without SSO?

Yes, technically. SCIM only needs an endpoint and a credential, and it does not care how users authenticate. In practice almost nobody does it, because the same buyer who asks for provisioning asks for SSO in the same breath.

Does SAML handle deprovisioning?

No. SAML has no mechanism to remove access. A departed employee simply stops logging in while their account stays active. That gap is the single strongest argument for adding SCIM.

Is SCIM more secure than SAML?

They secure different things, so the comparison does not really hold. What is true is that a SCIM endpoint is one of the most sensitive APIs you will expose, since it can create and disable accounts. Serve it over TLS only, scope the token to least privilege, rotate it on a schedule, and log every provisioning event.

What about OIDC instead of SAML?

OIDC answers the same question SAML does, in JSON over HTTP rather than XML through the browser, and it pairs with SCIM identically. Newer integrations tend to prefer OIDC. Enterprise buyers with older infrastructure still ask for SAML by name.

Which should we implement first?

SAML, usually. It unblocks the “do you support SSO?” question immediately and is the lighter lift. Just be aware SCIM is the harder retrofit, because adding it later means reconciling accounts that already exist against the directory.

The one-line version

SAML gets the user through the door. SCIM decides whether they have a door at all.

For the full protocol reference, including the SCIM schema, endpoints, and how SCIM compares to just-in-time provisioning, see what SCIM is and why it matters. For the wider lifecycle picture, see user provisioning explained, and for the implementation side, building and testing a SCIM API. And if you are building or debugging a SCIM endpoint, our free SCIM Endpoint Tester fires live requests from the browser and shows you exactly what comes back.

Want SAML and SCIM both handled without maintaining the plumbing? See Skycloak pricing.