Just-in-Time provisioning is a process used in identity and access management systems to create user accounts on the fly as they sign in to a system for the first time. This article explains the basics of Just-in-Time provisioning and answers common questions about its implementation.
Before we discuss Just-in-Time provisioning, imagine you’re building a SaaS B2B app and want to support membership features, allowing members to easily join your workspace (tenant). What features would you propose? Here’s a checklist for you:
Just-in-Time (JIT) provisioning is a process used in identity and access management systems to create user accounts on the fly as they sign in to a system for the first time. Instead of pre-provisioning accounts for users in advance, JIT provisioning creates and configures the necessary user accounts dynamically when a user authenticates. Just-in-time provisioning is a popular feature with its own characteristics, such as efficiency, no administrative involvement, and automated organization membership, etc. Now that you understand the basics of Just-in-Time provisioning, you might have several questions as you dive deeper into real-world product development. I’ll address these questions, which can be controversial and highly dependent on your specific business cases.
Do you need to implement Just-in-Time provisioning for your product?
These cases are common when building a B2B app that involves multi-tenant architecture, enterprise SSO, working with enterprises, or requiring team onboarding features. Here are some sample scenarios your client may encounter.
Rapid onboarding
You have a client experiencing frequent hiring or rapid growth can use JIT provisioning to quickly set up user accounts for new employees. Let’s take an example:
Sarah is a new employee at Company SuperFantasy, which uses Okta as its Enterprise Identity Provider. The HR team add her as an business identity sarah@superfantacy.com in Okta just one time. When Sarah uses this email to sign in to a corporate-used productivity app called Smartworkspace for the first time, the system automatically creates an account and provisions the right role for her within the company’s workspace. This way, neither Sarah nor the HR team at SuperFantasy needs to go through multiple steps for account creation and role assignment.
Mergers, acquisitions, and temporary workers
You have a client experiencing merging or acquiring others, JIT provisioning can simplify the process of granting access to the acquiring company’s systems for many new users. Let’s take another example,
Peter works for MagicTech, which was recently acquired by SuperFantasy. MagicTech is a smaller organization without enterprise SSO but uses Smartworkspace too where Peter already has a business account.
The HR team can add Peter in Okta. When Peter logs into Smartworkspace for the first time through Okta, the system automatically links his existing business account and grants the appropriate access to SuperFantasy.
The scenarios above are ideal for implementing the JIT feature.
Is it specific to SAML and Enterprise SSO?
Just-in-time (JIT) provisioning is often associated with Single sign-on (SSO) in SAML authentication, but it is not exclusive to SAML. JIT provisioning can also be used with other authentication protocols like OAuth 2.0 and OpenID Connect, and it doesn’t always require an Enterprise SSO set-up.
For instance, email-based JIT provisioning can streamline team onboarding by automatically adding users to a workspace based on their email domain. This is particularly useful for organizations that lack the budget and resources to purchase and manage enterprise SSO.
The fundamental idea behind JIT provisioning is to automate user account creation or updates when a user first attempts to access a service, regardless of the specific protocol used.
Does it apply to new or existing users of the app?
This is a tricky question. Just-in-time (JIT) provisioning generally refers to the first attempt to access an app. However, different products perceive this functionality differently. Some use JIT provisioning just for identity and account creation, while others also include Just-in-Time account updates, such as re-provisioning and attribute synchronization.
In addition to automatic user creation, SAML JIT Provisioning allows granting and revoking group memberships as part of provisioning. It can also update provisioned users to keep their attributes in the Service Provider (SP) store in sync with the Identity Provider (IDP) user store attributes.
For example, in Oracle Cloud, Just-in-Time provisioning can be configured in various ways.
- Just-in-Time creation
- Just-in-Time update Administering Oracle Identity Cloud Service: Understand SAML Just-In-Time Provisioning.
If you do want to consider the subsequent existing user sign-in scenario, make sure you have a robust provisioning system along with your JIT system. For example,
- Conflict resolution: Your system should have a strategy for handling conflicts if an account already exists with different information than what’s provided by the IdP during the JIT process. This may require detailed control of your organization’s policies and IdP configuration.
- Audit trails: It's important to maintain logs of both new account creations and updates to existing accounts through JIT processes for security and compliance reasons.
- Performance: While JIT provisioning happens quickly, consider the potential impact on sign-in times, especially for existing users if you're updating their information at each sign-in.
- Data consistency: Ensure that your JIT provisioning process maintains data consistency, especially when updating existing user accounts.
💡 Logto offers basic control of just-in-time updates at the Enterprise SSO level. We’ll cover this in more detail later in the article. Learn more👇
What is the difference between JIT and SCIM?
In addition to Just-in-Time (JIT) provisioning, you may have heard of SCIM (System for Cross-domain Identity Management). SCIM is an open standard protocol designed to simplify and automate user identity management across different systems and domains. It is commonly used in Directory Sync scenarios.
The main difference between JIT and SCIM is that JIT creates accounts during the user’s sign-in attempt, while SCIM can provision users through an offline automated process, independent of user login attempts.
This means JIT focuses on new user onboarding, while SCIM focuses on the full lifecycle management of users.
Furthermore, JIT is often an extension of SAML and lacks a standardized implementation across systems, whereas SCIM is a well-defined, standardized protocol (RFC 7644) for identity management.
Some larger organizations use SCIM for account provisioning, integrating it with their own systems. This can be very complex and vary case by case. These organizations often have a provisioning system that involves both automated processes and manual admin involvement.
Just-in-Time provisioning in Logto
SSO Just-in-Time provisioning and Email domain Just-in-Time provisioning are what we embrace in Logto.
In Logto, we have this feature set at the organization level that allows users to automatically join the organization and receive role assignments if they meet specific criteria.
We implement the JIT feature at its most scalable and secure level to simplify and automate the provisioning process for developers onboarding their clients. However, like we discussed earlier, since provisioning systems can be complex and tailored to your clients’ specific needs, you should leverage Logto’s pre-built JIT features, your careful system design, and the Logto management API to construct a robust provisioning system.
Let’s take this diagram to see how it works in Logto,
💡 Just-in-time (JIT) provisioning only triggers for user-initiated actions and does not affect interactions with the Logto management API.
Enterprise SSO provisioning
If you have Enterprise SSO set up in Logto, you can select your organization enterprise SSO to enable just-in-time provisioning.
New or existing users signing in through enterprise SSO for the first time will automatically join the organization and get default organization roles.
The following table list out the potential flows:
Email domains provisioning
If an organization doesn’t have a dedicated enterprise SSO, you can use email domains to enable Just-in-Time provisioning. This usually happens to smaller businesses that don’t have the budget for enterprise SSO but still want some level of member onboarding automation and security management.
When users sign up, if their verified email addresses match the configured email domains at the organization level, they will be provisioned to the appropriate organization(s) with the corresponding roles.
Email domain provisioning works for:
- Email sign-up authentication
- Social sign-up authentication
💡 Why doesn’t email domain provisioning apply to the existing user sign-in process?
Existing user sign-in requires further control to determine if they can be provisioned to a specific organization or granted a role. This process is dynamic and depends on specific use cases and business needs, such as subsequent log-in strategies and organization-level policies.
For example, if you enable email domain provisioning for an existing user and later want to onboard another group of users with a different role, should the previously onboarded user be assigned the new role you set up?
This creates a complex scenario for “Just-in-Time updates”. The exact behavior often depends on how the application, organization setting and IdP integration are configured. We give this control to our developers, allowing you to design your provisioning system freely and handle the most frequent scenarios for new account creation and organization onboarding.
Email flow
Social flow
Handling email domain provisioning and enterprise SSO potential conflict
If you initially set up email domain provisioning and later configure an Enterprise SSO with the same email domain, here's what happens:
When a user enters their email address, they will be redirected to the SSO flow, bypassing the email authentication. This means the JIT process won’t be triggered.
To address this, we will show a warning message when configuration. Ensure you handle this flow by selecting the correct SSO to enable just-in-time provisioning, and do not rely on email domain provisioning.
Default organization roles
When provisioning users, you can set their default organization roles. The role list comes from the organization template, and you can choose a role or leave it empty.
Enterprise SSO Just-in-Time update
Luckily, we already have this feature built into Enterprise SSO! You can choose whether profile information is synced to Logto at the first sign-in or every sign-in. We’ll also consider adding more features like role and organization mapping and reprovisioning in the future.
Check this to learn more.
The Just-in-Time feature is available immediately in Logto. Sign up for Logto today and start automating your clients’ membership onboarding.
Try Logto Cloud for free
Top comments (1)
Great explanation and good to see Logto offers Just-in-Time provisioning, also known as synchronous provisioning.
Just-in-Time provisioning is in my opinion the most ideal form of provisioning. However, being a developer of the open source foundation backing scim.dev, I have dived extensively into this protocol and believe supporting this protocol for user account creation (in identity provider systems, and in client applications) is essential, simply because "just-in-time" is sometimes too late: for example when trying to assign tasks to other users (who may not have logged in) in systems.