Just-in-time (JIT) provisioning creates or updates a user account the first time that person signs in through a SAML or OIDC identity provider, using the claims in the login response. SCIM provisioning is the opposite direction: the customer’s directory pushes creates, updates and deactivations to your app on its own schedule, whether or not anyone has logged in. JIT is enough when you only need accounts to appear without manual setup, and SCIM becomes necessary when a customer needs leavers removed, groups kept in sync, or evidence for an auditor.
If you run a B2B SaaS and your first enterprise customer has just asked whether you “support SCIM”, this post explains what they mean, what JIT already covers, and how to choose. It also shows where each one lives in Keycloak 26.8, which is what Skycloak runs as a managed service (identity management as a service built on upstream Keycloak).
What is JIT provisioning?
JIT provisioning means your identity layer creates the user record on demand. The user clicks “Log in with SSO”, authenticates at the customer’s identity provider, and your system receives an assertion (SAML) or ID token (OIDC) containing an email address, a name and perhaps group claims. If no matching account exists yet, one is created from those claims, and if one exists it can be updated from them.
The appeal is that nobody has to do anything in advance. The customer’s IT admin configures the SSO connection once, and employees appear in your product as they start using it. There is no API for the customer to call and no token to hand them, which is why almost every SSO setup starts here.
The limit is in the first sentence of the definition: it only happens at login. An account that has never logged in does not exist, and an account whose owner has left the company is never touched, because nothing at your end is told that they left.
What is SCIM provisioning?
SCIM (System for Cross-domain Identity Management) is a standard REST API for moving identity data between systems, defined in IETF RFC 7644 with the user and group schema in RFC 7643. A directory such as Microsoft Entra ID or Okta acts as the SCIM client and calls your SCIM endpoint whenever something changes: a new hire is assigned to your app, a name changes, a user is moved between groups, or a user is deactivated.
Because the directory initiates the calls, SCIM can create an account before the person ever logs in, and it can disable one the day HR marks the person as departed. If you want the long version, our user provisioning overview compares JIT and SCIM with manual and scripted provisioning. Our SCIM protocol explainer covers the schema and the flows, and SCIM vs SAML clears up why the two are not alternatives to each other.
JIT vs SCIM: how do they compare?
| JIT provisioning | SCIM provisioning | |
|---|---|---|
| Who triggers it | The user, by logging in | The customer’s directory, on a schedule or on change |
| Setup effort for the customer | None beyond the SSO connection | Admin enables provisioning, pastes a base URL and token |
| Setup effort for you | Attribute mappings on the connection | A SCIM endpoint, authentication for it, and support for it |
| Accounts before first login | No | Yes |
| Leavers and deactivation | Not handled | Handled when the directory sends the update |
| Group and role sync | Only what the login claims carry, refreshed at each login | Group objects pushed as they change |
| Attribute freshness | As fresh as the user’s last login | As fresh as the last sync |
| Licence counting | Counts only people who have logged in | Can count everyone assigned, including people who never log in, depending on how you bill |
| Audit evidence | Login events | A record of provisioning and deprovisioning calls |
The row that matters most is leavers. With JIT alone, a departing employee is removed from the customer’s directory and can no longer sign in through SSO, but their account, their data and any API keys or sessions they hold in your product stay exactly as they were.
Why do enterprise buyers ask for SCIM?
The question usually arrives in a security questionnaire, and it is almost always about deprovisioning. Auditors reviewing access controls under frameworks such as SOC 2 want to see that access is removed promptly when employment ends, and a customer’s security team would rather prove that with an automated process than with a quarterly spreadsheet review of who still has an account in each SaaS tool.
There is a practical side as well. If a customer pays per seat, they want unused accounts reclaimed without filing a ticket, and if their app permissions are driven by directory groups, they want a group change to take effect without waiting for the next login. Both of these need the directory to push changes, which is the part JIT cannot do.
How does deprovisioning actually fail with JIT only?
Suppose a customer’s contractor leaves on a Friday and is deactivated in Entra ID the same afternoon. The next time the contractor tries to sign in to your product through SSO, Entra refuses, so the front door is closed. Behind that door, three things can still be true:
- The contractor’s account in your product is still enabled, so anything that authenticates without SSO, such as a personal API key or a password set before SSO was enforced, still works.
- Any session or refresh token issued before Friday stays valid until it expires, unless the customer’s identity provider sends a back-channel logout that your identity layer acts on, because nothing checks the upstream directory on every request.
- The account still holds its seat, its role and its data, and appears in admin lists as an active user.
You can narrow the gap with short session lifetimes and a periodic review, but a review is a human process and it runs at the pace of whoever owns it. SCIM replaces the review with an event.
Which should you choose?
| Situation | Reasonable choice |
|---|---|
| Early-stage product, a handful of SSO customers, no questionnaire asking about deprovisioning | JIT only |
| Customers are small teams who rarely have leavers, and you can review accounts every quarter | JIT plus a scheduled access review |
| A prospect’s security review lists automated deprovisioning as a requirement | SCIM from the start |
| Large customers with directory groups mapped to roles in your product | JIT and SCIM together |
The last row is the most common end state, and the two are not in conflict. SCIM keeps the account list and group membership correct, while JIT remains the path that links a person’s SSO login to the account SCIM created for them. A related decision, which many teams hit at the same time, is how to choose an SSO provider for B2B SaaS.
How do JIT and SCIM work on Keycloak?
Keycloak does JIT through identity brokering. When a user logs in through a brokered SAML or OIDC identity provider for the first time, Keycloak runs the first broker login authentication flow, which creates a local user linked to the external identity (or, if a user with the same email already exists, asks to link the two). The Keycloak Server Administration Guide describes this flow, along with the identity provider setting called Sync Mode, which controls whether identity provider mappers refresh user data on later logins: import does not update user data after the first login, force updates it on every login, and legacy keeps the older behaviour. Individual mappers can override this with their own Sync Mode setting. Our guide to attribute mapping during OIDC identity brokering shows how to map claims to user attributes, and the identity providers recipe walks through connecting one.
For SCIM, Keycloak 26.8.0 (tagged 1 October 2026) promoted the native SCIM API from preview to supported, according to the 26.8 release notes, and the 26.8 upgrading guide confirms the scim-api feature is now enabled by default. The API is inbound only, meaning Keycloak receives users and groups from a directory, and each realm has its own toggle. The details and current limits are in our Keycloak 26.8 SCIM post, and you can test an endpoint with the SCIM tester. The feature pages for SCIM and identity providers describe how both fit into Skycloak.
One timing point is worth knowing. If you already ran SCIM through a custom extension or a separate service because upstream Keycloak lacked it, the 26.8 change gives you a supported path to consider, but it does not remove the need to test your customers’ directories against it before you promise anything.
What should you check when the first customer asks for SCIM?
A short checklist keeps the conversation concrete:
- Ask which directory they use (Entra ID, Okta, Google Workspace, something else) and whether they need users, groups, or both.
- Confirm what must happen on deactivation: disable the account, delete it, or revoke sessions as well.
- Decide how SCIM-created users link to SSO logins, normally by matching on email or a stable external ID.
- Check that your session and refresh token lifetimes are short enough that a deactivated user loses access in a time you can state to the customer.
- Run a test sync against a non-production tenant before the customer’s security team does.
Frequently asked questions
Is JIT provisioning the same as SCIM?
No. JIT provisioning happens inside the login, creating or updating a user from the claims in the SAML or OIDC response. SCIM is a separate REST API that a directory calls independently of any login.
Does JIT provisioning delete or disable users?
No. JIT only creates and updates accounts at login, so it cannot disable an account for someone who has stopped logging in. Deprovisioning needs SCIM, a periodic access review, or a custom process.
Can I use JIT and SCIM together?
Yes, and many B2B products do. SCIM keeps accounts and groups in step with the directory, and JIT (or simply the SSO login) links each person to the account when they arrive.
Do I need SCIM to pass a SOC 2 audit as a vendor?
SOC 2 does not name SCIM. It asks that access is removed in a timely way when it is no longer needed, and SCIM is one way a customer can show that for your product, which is why their questionnaires ask for it.
Does Keycloak support SCIM?
Yes. Keycloak 26.8.0 made the native SCIM API a supported feature that is on by default, though it is inbound only and each realm has to enable it.