SCIM vs SAML: one creates the account, the other signs the user in

SAML and SCIM are often listed together in procurement checklists, as if they were two flavors of the same feature. They solve different halves of the same problem:

• SAML answers "can this user sign in?"
• SCIM answers "does this user's account exist, and is it up to date?"

A company that enables SAML but not SCIM still creates accounts by hand. A company that enables SCIM but not SAML still has users signing in with local passwords. Most enterprise deployments need both.

SAML: authentication, at sign-in time

SAML 2.0 is a single sign-on protocol. When a user opens an application, the application redirects them to the identity provider, which authenticates them and returns a signed assertion. The application trusts the assertion and starts a session.

The account has to exist before this happens. If the application has never seen the user, the assertion either fails or the application creates a bare account from the assertion's attributes — the "just-in-time" model. Either way, SAML only runs when someone signs in.

SCIM: account lifecycle, in the background

SCIM (System for Cross-domain Identity Management) is a standard REST API for managing accounts. It is defined by two IETF RFCs: RFC 7643 (the user and group schema) and RFC 7644 (the protocol: create, read, update, delete, filter, bulk operations).

The identity provider acts as the SCIM client. When an employee joins, changes teams or leaves, the identity provider calls the application's SCIM endpoint:

• POST /Users — create the account.
• PATCH /Users/{id} — update the name, department or active flag.
• DELETE /Users/{id} — delete it, or deactivate it by setting active: false.
• GET /Users?filter=userName eq "alice@example.com" — look up an account.

Because it is a plain REST API, SCIM runs whether or not the user is signing in. That is what makes deprovisioning work: when someone leaves, the account is disabled in every connected application within minutes, without waiting for a login that will never come.

Side by side

SCIM versus just-in-time provisioning

JIT provisioning is the shortcut: the application creates an account the first time a user signs in, using the SAML assertion. It removes the manual setup step and is good enough for many internal tools.

It does not cover:

• Deprovisioning. A user who never signs in again keeps their account forever.
• Attribute updates. A name or department change is only picked up on the next login.
• Accounts for services and shared mailboxes that never sign in.

SCIM is the answer when those gaps matter — which, in enterprise procurement, is usually the moment a security questionnaire arrives.

What to check before rolling out SCIM

1. Does the application support SCIM 2.0, and which operations? Some support create and update but not delete; some do not support groups.
2. What is the identity provider's SCIM client like? Okta, Microsoft Entra ID and OneLogin each implement their own subset and quirks.
3. How are users matched? The userName attribute is the usual key; decide what happens when the email changes.
4. What happens on delete? Soft-deactivate is safer than hard delete, especially for audit trails.
5. Are groups provisioned too? Group membership is where role mapping usually lives.

How Casdoor handles both

Casdoor is a SAML 2.0 identity provider and a SCIM 2.0 server. Applications can sign users in with SAML or OIDC, and an upstream identity provider can create and update accounts through the SCIM endpoint, so the account exists before the first sign-in. Casdoor also has a SCIM syncer for pulling users from an external SCIM source. See the SCIM docs.

Related reading: what SCIM is, SAML vs OIDC and identity provider vs service provider.

Casdoor is open source and self-hostable, with a hosted option from $9 per month and no per-user fees.