SCIM vs JIT: key differences explained

Just-In-Time provisioning (JIT) and System for Cross-domain Identity Management (SCIM) are both user provisioning strategies that automate account creation and management. And while they might seem similar they are designed for different use cases.

In this article, we’ll break down the differences between JIT and SCIM, discuss how they work, and look at their pros and cons to help you decide which one you should support. We will also see what SCIM brings to the table even if you are already using JIT and SAML group role assignment.

What is JIT?

‍Just-In-Time provisioning (JIT) automates the creation of user accounts, and as the name suggests, it does this on the fly during the user’s first login using SSO. Admins don’t have to pre-provision accounts before the user accesses an app.

With JIT, as soon as you configure an SSO integration between your app and your customer’s IdP, any user authenticated by the IdP can automatically access to your app, and be subject to the access controls and policies set by the organization. Your app uses the data sent from the SSO provider to create the account.

The big drawback of JIT is that it doesn't manage ongoing account updates or deletions after the initial setup. Your customers need to set up other processes to deactivate or update user accounts.

How JIT provisioning works

JIT provisioning leverages the SSO process to trigger the creation of user accounts. So your customer’s IT team has to first enable SSO between your app and their IdP for it to work.

Here’s how the JIT provisioning process looks like:

1. When a user attempts to log into your app for the first time, they’re redirected to their IdP.
2. The IdP authenticates the user and redirects them back to your app with a token containing their identity data (such as email address, role, name, and any other relevant details you need to create a user account).
3. After validating the token, your app checks its database to see if an account that matches the user's identity already exists.
4. If no matching account is found, JIT provisioning activates. Your app uses the provided identity data to automatically create a new user account in real time.

For the user, this entire process is seamless. They simply log in using their SSO credentials and gain immediate access to your app, even if it’s their first time using it. During subsequent logins, your app will recognize the user's account (which was created during the first login) and won’t create another account.

Pros of JIT provisioning

• Reduced administrative work: JIT significantly cuts down on the administrative effort required to provision users – admins don’t have to manually create user accounts for every employee that needs access to your app, they get immediate access on their first login.
• More paid seats: By allowing users to self-provision their access through JIT provisioning, you essentially empower entire organizations to onboard themselves onto your app. Because of this ease of access, your app can quickly increase the number of paid seats in your app, from tens to hundreds or even thousands of users.
• Less dormant or inactive accounts: By only creating accounts when needed, JIT provisioning reduces the risks associated with inactive or dormant user accounts – if users are able to log in to your app without SSO, then fewer unused accounts can mean fewer potential targets for hackers. Note, the accounts have to be closed once they’re no longer in use, otherwise the security risk is reintroduced.
• Speed of access: Users don’t have to wait for admins to see and approve their access requests when they want to use an app. They can just sign in to the app and instantly get access.

Cons of JIT provisioning

• Security risks: JIT doesn’t support user account deletions or suspensions. This is a security risk if your customer doesn’t have other processes in place to remove accounts from your app. A user might end up retaining access long after they’ve left the company.
• Poor user collaboration experience: If your app allows users to work together, JIT provisioning will prevent your users from collaborating with peers who haven’t signed into your app yet. This is because a user must first log in before their account is created and becomes accessible to the others within the app. Consider a document review app. If a user wants to assign a document to a colleague for review, that colleague's account must already exist within the app. With JIT provisioning, if the colleague has never logged into the app, their account doesn't exist yet, making it impossible to assign them the document for review. An alternative is using SCIM to preemptively provision accounts.
• Limited user data: The depth of user data is contingent upon what is provided at the time of authentication, which might be insufficient for your app. This is different from SCIM, whose schema can be extended to include custom attributes — i.e. any extra piece of user information your app might need.

What is SCIM?

SCIM (System for Cross-domain Identity Management) provisioning is an open standard for automating the exchange of user identity information between different systems, typically an identity provider (IdP) and a service provider (i.e. your app).

SCIM uses Directory Providers to manage all aspects of a user throughout their lifecycle from creating and updating user accounts to deleting them when the user is de-provisioned, and defines a standard schema to represent user and group identities and RESTful endpoints for communication. The standardized format ensures that your app and the IdP understand and interpret user data in the same way.

How SCIM provisioning works

SCIM provisioning syncs user changes between your customer’s IdP and your app automatically in real time. When an IT admin creates, updates, or removes a user from their IdP, SCIM propagates these changes to your app.

Here’s how SCIM provisioning works:

1. When a change occurs in the IdP (e.g., a new employee is added, an existing employee's role is updated, or an employee leaves the company), the IdP sends a notification to the service provider in a standardized format (defined by SCIM). This data includes name, email, employee ID, and roles.
2. The service provider processes the received data and updates the corresponding user account or creates a new one if necessary.

This process is ongoing, ensuring that user information in the service provider is always in sync with the IdP.

Initially, SPs added SCIM support because their app’s user experience depended on being able to know about customers shortly after they were added to the system. Over time, the focus expanded to include security as a significant factor for adopting SCIM.

Pros of SCIM provisioning

• Interoperability: Because SCIM defines standardized JSON payloads and endpoints, it enables uniform user provisioning processes across different platforms. Without a standardized protocol like SCIM, integrating each new IdP or service into your app would require custom development work to map between the disparate user identity models of each of your customer’s IdPs.
• Efficiency in identity management: Automating user provisioning and de-provisioning means your customer’s admin teams don’t have to manually update or delete users from your app which, like any manual process, can be prone to errors - such as an admin forgetting to revoke all access permissions and consequently exposing your app to unauthorized users.
• Security: With SCIM’s ongoing synchronization, your app always has up to date information on the user. And, you’re able to ensure they have the appropriate level of access to your app or specific parts of it, based on their current roles and access rights.
• Scalability: SCIM can handle bulk requests, meaning admins can provision hundreds or even thousands of user accounts at once.
• Compliance: Being able to prove that in the case of de-provisioning employee access is removed immediately is a requirement for SOC2. Although SOC2 does not require SCIM, it does require a process for off-boarding users and documentation (logs) that show you have done it and they don’t have access anymore. If you don’t have something like SCIM, then you should do user de-provisioning in some other manual way.
• Improved user experience: It enables faster onboarding and offboarding of employees. For example, with SCIM users can be at-mentioned in your app before they sign in the first time. This can be particularly helpful for onboarding processes.

Cons of SCIM provisioning

• Complex implementation: Setting up SCIM can be complex, especially if you’re integrating with multiple IdPs. Because despite the standardization efforts of SCIM, its implementation can differ from one IdP to another. You may need to write custom code to map data correctly to your app’s data model and to handle SCIM requests in a way that aligns with each IdP’s specific requirements. This problem goes away when you use WorkOS which manages all the quirks of different IdPs.
• It requires pre-provisioning: Your customers have to take the time to pre-provision users beforehand i.e. they have to give their employees permission to access your app way ahead of time. This is unnecessary with JIT as we’ll see in the next section.

What are the benefits of SCIM if you already support JIT and SAML group role assignment?

• Real-time de-provisioning and state changes: With SCIM users immediately lose access to the application when they are de-provisioned or unassigned from the app in their IdP. Without SCIM they would only lose access once any current sessions expire. This is a pretty major technical consideration and often required from a compliance perspective (e.g. you need to prove that employee access is removed immediately for SOC2). While SAML is stateless (there is no way to check whether a SAML session is still active), SCIM gives you state changes. The limitation of SAML is the IdP would never tell you when a user got removed. The only way to know when a user lost access to a SAML app is that when the user would attempt to log in they get an unauthorized error of some kind. That is not the case with SCIM. With SCIM provisioning all user changes are synced between your customer’s IdP and your app automatically in real time. When an IT admin creates, updates, or removes a user from their IdP, SCIM propagates these changes to your app. With SCIM users immediately get a new role assigned when their IdP groups change. There is no need for them to log out and log back in to pick up the change.
• User pre-provisioning: While we mentioned pre-provisioning as one of the cons of SCIM, it can also be a pro. While your customers have to take the time to pre-provision users beforehand, this offers some advantages, for example, users can be at-mentioned in your app before they sign in the first time. This can be particularly helpful for onboarding processes.
• More robust role mapping: Setting up SSO Group and Role mapping is more brittle with SAML compared to SCIM. The admin has to manually copy paste the group names vs automatic hydration in SCIM.
• Longer user sessions: SCIM allows developers to keep longer session lengths (i.e. >24 hours) which is much better UX.

Which is right for you?

If you have to choose between SCIM and JIT, prioritize SCIM. It’s much more widely used by enterprises due to its ability to manage the entire user lifecycle (create, update, delete accounts) at a large scale.

However, if you have the time and the engineering resources, you should support both JIT and SCIM to cater to a broader customer base – some of your customers might only be using SSO and JIT, while others might be using SCIM.

JIT provisioning is popular among small organizations to automatically give access to their few employees. At the enterprise level, most organizations prefer SCIM provisioning as it becomes extremely important to keep user authorization changes in sync across the hundreds of apps they use.

Next steps

Getting enterprise-ready means supporting enterprise features like JIT and SCIM provisioning from Day 1. With WorkOS, you can add both using a single API-based integration. You can add JIT via SSO, and use Directory Sync to add SCIM provisioning with just a few lines of code.

• Get started fast: With SDKs for every popular platform, and Slack-based support, you can implement Directory Sync in minutes rather than weeks.
• Events-based processing: While webhooks are also supported, WorkOS’ Events API means every SCIM request is processed in order, and in real-time. You’ll never miss a provisioning request again.
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard - whether they’re syncing 10 or 10,000 users with your app.

Sign up with WorkOS today.