Just-in-time (JIT) provisioning creates an account in a target application when an eligible user completes their first successful federated sign-in. The identity provider (IdP) authenticates the user and sends identity data, while the target application decides whether to match an existing account, create a new one, assign permissions, or update supported attributes.
JIT provisioning is not the same as single sign-on (SSO). SSO authenticates the user; JIT creates the application account when needed. JIT also does not provide complete joiner-mover-leaver lifecycle management. Organizations that need ongoing account, group, role, and offboarding synchronization usually require the System for Cross-domain Identity Management (SCIM) or another lifecycle process.
Key Takeaways
- JIT provisioning creates a user account when an eligible user first accesses an application instead of creating the account in advance.
- SSO handles authentication; JIT handles account creation. A successful SSO login does not automatically mean JIT provisioning is enabled.
- SCIM supports broader identity lifecycle management, including account creation, updates, group management, and deprovisioning where supported.
- JIT and SCIM can work together: JIT can handle first-access account creation, while SCIM can manage ongoing identity changes and offboarding.
- JIT provisioning differs from JIT privileged access, which provides temporary elevated permissions rather than creating user accounts.
What is JIT provisioning?
JIT provisioning is an account-creation method triggered by a user’s first successful federated login. Instead of creating every application account in advance, an organization assigns eligible users to the application in its IdP. The target application creates a user record when an assigned user first signs in, provided JIT is supported and enabled.
The target application controls the provisioning behavior. Its configuration determines:
- Which federated sign-ins are eligible to create accounts
- How incoming identities are matched to existing users
- Which attributes are required for account creation
- Which default role, license, or permissions a new user receives
- Whether attributes or roles can be updated during later sign-ins
Documented implementations commonly use Security Assertion Markup Language (SAML), although some applications also support JIT through OpenID Connect (OIDC). Protocol availability and provisioning behavior remain application-specific.
How JIT provisioning works at first sign-in
A typical first-login flow has five steps:
- The administrator assigns the user to the application. The assignment may be direct or based on a group, depending on the IdP and application.
- The user authenticates with the IdP. The IdP applies its configured authentication and access policies.
- The IdP sends identity data. A SAML assertion or OIDC claims carry identifiers and other mapped attributes to the target application.
- The target application looks for a matching account. If no match exists and the user is eligible, the application creates an account. If a match exists, it uses that account and may update supported attributes.
- The application authorizes the user. It applies the configured role, group, license, or default permissions and completes sign-in.
This sequence is reflected in application-specific JIT documentation from vendors such as Salesforce, Atlassian, and Databricks. Their exact prerequisites and mappings should not be treated as universal requirements.
The IdP, assertion or claims, and target application have different roles
The IdP authenticates the user and sends the configured identity attributes. It may also determine whether the user is assigned to the application.
The SAML assertion or OIDC claims carry identity data such as a persistent identifier, email address, given name, surname, or group information. They do not create the account by themselves.
The target application, also called the service provider in a SAML flow, interprets that data. It applies its matching, provisioning, and authorization rules. A correctly authenticated SSO response can therefore succeed at the federation layer but still fail to create an account if JIT is disabled, required attributes are missing, or the user is not eligible.
What happens when an account already exists
The target application normally attempts to match the incoming identity before creating an account. Depending on the application, matching might use a federated identifier, username, email address, or another immutable field.
If the application finds a match, it signs the user into that account. It may also update selected profile or authorization attributes if sign-in-time updates are supported and configured.
If the incoming value does not match the application’s existing-account rules, the application may reject the sign-in or create a second account. For example, a changed email address can cause duplication when email is the matching field and the existing account still contains the old value. Administrators should verify case handling, aliases, renamed users, and identifier normalization rather than assuming that all applications match accounts the same way.
JIT provisioning vs. SSO, SCIM, and just-in-time access
SSO, JIT provisioning, and SCIM solve related but separate identity problems.
| Capability | Primary purpose | Typical trigger | Ongoing lifecycle management |
|---|---|---|---|
| SSO | Authenticates a user through a trusted IdP | Each federated sign-in | No account creation or synchronization is implied |
| JIT provisioning | Creates an application account when first needed | First successful eligible sign-in | Limited; later updates depend on the application |
| SCIM | Exchanges identity data between an identity system and an application | Directory or provisioning-service changes | Can support account creation, modification, group management, disablement, and deletion where implemented |
SCIM is an HTTP-based identity-management protocol defined by RFC 7644. It provides operations for User and Group resources, including creation, retrieval, modification, and deletion. However, each SCIM service provider decides which operations and attributes it supports. Deprovisioning may disable an account, delete it, or follow another application-specific process.
Why temporary privileged access is different
“JIT access” can also refer to just-in-time privileged access. That is a separate concept from JIT provisioning.
- JIT provisioning creates a user account in an application at first sign-in.
- Just-in-time privileged access grants elevated permissions for a limited period or approved task, then revokes those permissions.
An existing administrator might receive temporary elevated access without any account being created. Conversely, a JIT-provisioned user may receive only a basic, permanent role. Administrators should distinguish the two concepts when evaluating products or writing access policies.
Prepare and configure JIT provisioning
Successful JIT deployment depends more on target-side matching and authorization rules than on the account-creation switch itself.
Confirm application support, eligibility, and SSO prerequisites
Before enabling JIT, verify:
- The target application supports JIT for the intended federation protocol
- JIT is included in the organization’s application plan or configuration
- SAML SSO or OIDC federation is working before provisioning is tested
- JIT must be enabled explicitly, or is enabled automatically for that application
- Users must be assigned through the IdP, a group, an application policy, or another eligibility rule
- Required application-side settings, licenses, verified domains, or administrator approvals are complete
- The application documents how it handles existing accounts and offboarding
SSO should be tested independently first. This separates authentication failures from provisioning failures and avoids troubleshooting both layers at once.
Map attributes and account-matching rules
There is no universal JIT attribute schema. Each application defines the fields required to create an account. Common fields include email address, display name, given name, surname, username, groups, and role-related values.
The most important design choice is the matching identifier. It should be stable, unique, and formatted exactly as the application expects. Before deployment, document:
- Which incoming claim or SAML attribute is used to find an existing account
- Whether the identifier can change when a user is renamed or changes email address
- Whether matching is case-sensitive
- How aliases and alternate email addresses are treated
- What happens if the identifier is missing or duplicated
- Whether existing local accounts require an identifier to be added before federation
Use the target application’s documented attribute names and formats. A technically valid assertion can still fail if, for example, the IdP sends surname while the application expects a different mapped attribute.
Set safe default roles and test least-privilege permissions
A newly provisioned account should receive only the access needed for its expected job. Avoid assigning administrative or broadly privileged roles as the default for every JIT-created user.
Check whether authorization comes from:
- A fixed default role in the application
- An IdP group or role attribute
- Application-side group membership
- A license or entitlement assigned after account creation
- A separate administrative approval process
If the application accepts role or group values from the IdP, test unknown, empty, and unauthorized values. Confirm that an invalid mapping fails safely instead of granting broader access or silently falling back to an unsuitable role.
Test and troubleshoot first-login provisioning
Do not validate JIT with only one new user. The test plan should cover account creation, matching, authorization, ineligible users, and subsequent changes.
| Test case | Expected result | Likely failure point if it does not work |
|---|---|---|
| New, assigned user | One account is created and the user receives the intended default access | JIT enablement, IdP assignment, required attributes, eligibility, or licensing |
| Existing matched user | The user enters the existing account without duplication | Matching identifier, email consistency, or normalization rules |
| User with a changed attribute or role | Supported fields change as documented, without creating another account | Sign-in-time update support, claim mapping, or role rules |
| Unassigned or ineligible user | No account is created and access is denied | Overbroad IdP assignment or target-side eligibility settings |
| User with a missing required field | Provisioning is rejected without creating a partial or incorrect account | Required attribute mapping |
| Disabled or removed user | Federated access and the target account behave according to the documented offboarding process | IdP policy, provisioning scope, SCIM configuration, or target-side account state |
Use dedicated test users rather than production identities where possible. Record the asserted identifier, mapped attributes, expected role, target-side account state, and final result for each test.
Trace failures in order
When first-login provisioning fails, investigate the flow from the IdP to the application:
- IdP assignment: Confirm that the user is assigned to the correct application and provisioning scope.
- Federated authentication: Verify that SSO itself succeeds and that the response reaches the intended tenant or application instance.
- Assertion or claims: Inspect the identifier and required attributes. Check names, formats, namespaces, capitalization, and empty values.
- Existing-account matching: Compare the asserted identifier with the actual value stored in the target application.
- JIT settings: Confirm that JIT is enabled and that the user meets target-side eligibility rules.
- Authorization: Check default roles, group mappings, license availability, and application-specific restrictions.
- Logs: Correlate IdP sign-in records with the application’s authentication, audit, or provisioning logs.
A useful diagnostic distinction is whether authentication failed, provisioning failed, or authorization failed. These stages may appear to the user as the same “access denied” message but require different fixes.
What happens after account creation?
JIT provisioning guarantees neither continuous synchronization nor automatic offboarding. After the initial account is created, behavior depends on the target application.
Sign-in-time updates depend on the application
Some applications can update names, email addresses, roles, or other attributes during later federated sign-ins. Others use JIT only for initial account creation, leave selected fields unchanged, or require SCIM or administrative changes for subsequent updates.
Test an intentional attribute change before relying on sign-in-time synchronization. Verify both the application profile and effective permissions; a displayed role value is not sufficient evidence that access changed as intended.
Blocking sign-in does not necessarily disable or delete the account
Disabling a user in the IdP or removing their application assignment can prevent federated authentication. It does not inherently disable or delete the user’s record in the target application.
Complete offboarding may require SCIM, a vendor connector, an API workflow, or a manual target-side process. Even with SCIM, an application may implement deprovisioning as soft disablement rather than deletion. Microsoft’s application-provisioning documentation illustrates how create, update, disable, and delete outcomes can depend on the target connector and application.
Administrators should test what happens to active sessions, assigned content, ownership, licenses, and the account record when a user leaves. Do not treat an IdP login block as proof that target-side access and data ownership have been fully resolved.
When to use JIT, SCIM, or both
Choose the provisioning model according to the lifecycle work the application must support.
Use JIT provisioning when:
- Accounts should be created only when assigned users first access the application
- Immediate first-login access is more important than pre-provisioning
- The application does not support SCIM or another suitable lifecycle connector
- Ongoing profile changes, entitlement updates, and offboarding can be handled through a verified separate lifecycle process
Use SCIM when:
- Accounts must exist before the user’s first login
- User attributes, groups, or entitlements must remain synchronized
- Directory changes should trigger provisioning updates
- Offboarding needs automated target-side disablement or deletion
- Administrators need visibility into provisioning operations independent of user sign-in
Use both when:
- The target application explicitly supports both methods
- Each method has a documented role—for example, JIT handles eligible first-login creation when no matching account exists, while SCIM handles supported ongoing updates and offboarding
- Account matching, role ownership, and deprovisioning behavior have been tested together
When both are enabled, document which system owns each attribute and operation. Otherwise, a login-time JIT update and a later SCIM synchronization could produce unexpected results if they apply different values.
For organizations building this kind of identity stack, Scalefusion OneIdP helps centralize access to work applications with SSO, SCIM-based user provisioning, MFA, and conditional access. Instead of treating provisioning as a standalone setting, IT teams can pair identity-based access with device trust signals, so users access applications only when both the user and the device meet the organization’s security requirements.
To see how these controls can work together in a broader identity and device access strategy, explore Scalefusion OneIdP.
FAQs
1. Does enabling SSO automatically enable JIT provisioning?
No. SSO authenticates users, while JIT creates target-application accounts. Depending on the application, JIT may be enabled automatically after SSO setup, require a separate setting, or not be supported. Confirm the application’s prerequisites and provisioning configuration.
2. Which user attributes does JIT provisioning require?
Requirements vary by application. A stable, unique matching identifier is essential, while email address, given name, surname, display name, groups, or role values may also be required. Use the target application’s documented claim names, formats, and matching rules.
3. Why might a first sign-in create a duplicate account?
A duplicate can be created when the asserted identifier or email does not match the field used to locate an existing account. Check renamed users, aliases, capitalization, identifier formats, and whether the existing account contains the expected federated identifier.
4. Can JIT provisioning change a user’s role at the next login?
Sometimes. Some applications support sign-in-time role or group updates, while others use JIT only for initial account creation. Verify the application’s role mapping and test a changed user to confirm the resulting permissions.
5. Does disabling a user in the IdP remove their application account?
Not necessarily. Disabling the IdP identity or removing its assignment may block federated sign-in without disabling or deleting the account in the target application. Verify the application’s SCIM, connector, API, or manual offboarding process.
