SCIM vs JIT provisioning: creating users is easy, removing them is not

Both just-in-time (JIT) provisioning and SCIM create user accounts automatically, so they get treated as interchangeable. They solve different halves of the lifecycle:

• JIT creates an account when a user signs in.
• SCIM manages accounts whether or not the user signs in — including deactivating them.

The first is a login feature. The second is a lifecycle feature. The gap between them is where offboarding incidents come from.

How JIT provisioning works

When a user signs in through SAML or OIDC for the first time, the application looks at the assertion or token, finds no matching account, and creates one from the claims. Subsequent logins update the attributes.

Strengths:

• Fast to ship. No extra API, no admin UI for provisioning.
• Zero-touch onboarding. The user's first login is the provisioning event.

Weaknesses:

• No deprovisioning. A user who leaves but never signs in again keeps access indefinitely.
• No updates between logins. A department change is only reflected the next time the user signs in.
• Nothing exists before first login, which breaks features that need the account in advance: assignments, licenses, shared files, audit scope.

How SCIM works

SCIM (RFC 7643 for the schema, RFC 7644 for the protocol) is a REST API the identity provider calls:

• POST /Users when someone joins.
• PATCH /Users/{id} when their attributes change.
• DELETE /Users/{id} or active: false when they leave.

Because it is out-of-band, it covers users who never sign in — including service accounts and shared mailboxes — and it deprovisions on the day the identity provider disables the account.

Side by side

Why deprovisioning is the real requirement

Most security questionnaires do not ask "can you create users automatically?" They ask "how quickly is access revoked when someone leaves?"

With JIT only, the answer is "when we notice." With SCIM, it is "when their identity provider account is disabled." That difference is the reason enterprise buyers ask for SCIM specifically.

SCIM also gives you a second useful property: group membership. If the customer's directory says a user is in the finance group, SCIM can carry that into your app and map it to a role, instead of asking an admin to assign it manually.

The practical pattern: both

Most mature deployments use both:

• SCIM for the customers who have it and ask for it. It becomes the source of truth for account existence.
• JIT as a fallback for smaller customers and for the first days of an integration, so a login never fails because provisioning has not run.

The rule of thumb: SCIM creates and owns the account; JIT never blocks a login. If SCIM is on for a tenant, a JIT login finds the existing account and only refreshes attributes.

What to check before shipping SCIM

1. Which operations does the customer's identity provider send? Okta, Entra ID and OneLogin differ in what they call and when.
2. Soft or hard delete? Deactivate by default; hard delete breaks audit trails and can cascade badly.
3. What is the match key? userName is standard, but it changes when people change names or emails.
4. Are groups included? Group provisioning is a separate schema object and often a separate phase.
5. Is the endpoint tenant-scoped? A SCIM token that can reach every tenant is a cross-tenant risk.

Related reading: SCIM vs SAML, what SCIM is and multi-tenant authentication.

Casdoor supports SCIM provisioning alongside SAML and OIDC, so accounts can exist and disappear independently of logins. See the SCIM docs.