Category: User Provisioning

Just-in-Time Provisioning

Also known as: JIT Provisioning, JIT provisioning, Just-in-Time (JIT) provisioning

Simply put

Just-in-Time (JIT) provisioning is a way of automatically creating a user's account in an application the first time they successfully log in, rather than setting it up in advance. This means the account is generated on demand during sign-in, so administrators do not have to create it manually beforehand. It is commonly used with single sign-on setups where a user's identity is confirmed by a separate identity provider.

Formal definition

Just-in-Time (JIT) provisioning is an automated account-creation mechanism in which a user profile is created dynamically in a target application at the moment of the user's first successful authentication, rather than being pre-provisioned. In most deployments it is triggered within a federated single sign-on flow: after the identity provider authenticates the user, attributes conveyed in the federation assertion are used by the service provider to create (and, depending on configuration, update) the local account. Reported implementations commonly operate over SAML-based SSO, though some vendors trigger JIT on authentication against a directory such as Active Directory; the exact protocol, attribute mapping, and update behavior vary by product and configuration. Note that JIT provisioning is a provisioning/lifecycle concern distinct from runtime authorization, and it differs from standards-based batch provisioning such as SCIM, which can create and manage accounts independently of a user's login event. This entry does not cover deprovisioning behavior, which is generally not addressed by JIT provisioning alone.

Why it matters

Just-in-Time provisioning addresses a common friction point in identity lifecycle management: the administrative overhead and delay involved in manually creating accounts in every application a user might need. By deferring account creation until the moment of a user's first successful authentication, organizations can avoid pre-provisioning accounts that may never be used, which reduces manual effort and can limit the accumulation of dormant, unused accounts in target applications. In federated single sign-on environments, this allows a user who has been authenticated by a trusted identity provider to gain a working local account in the service provider without an administrator staging it in advance.

Because JIT provisioning relies on attributes conveyed during the authentication flow, the accuracy of account creation depends heavily on correct attribute mapping and the trustworthiness of the identity provider's assertions. Misconfigured mappings can result in accounts being created with incorrect or incomplete attributes, and the on-demand nature of the mechanism means these effects surface at login time rather than during a controlled provisioning cycle. Teams should treat JIT configuration as a security-relevant control, not merely a convenience feature.

It is also important to understand what JIT provisioning does not do. It is a provisioning and lifecycle concern that is distinct from runtime authorization, and it generally does not address deprovisioning: an account created at first login is not automatically removed when a user leaves or loses eligibility unless a separate mechanism handles that. In most deployments, organizations that need coordinated joiner-mover-leaver lifecycle management pair JIT with, or replace it by, standards-based provisioning such as SCIM, which can create and manage accounts independently of a login event.

Who it's relevant to

IAM Engineers and SSO Administrators

Those configuring federated single sign-on need to understand how JIT provisioning maps assertion attributes into target applications and when it triggers account creation or updates. Correct attribute mapping and awareness of vendor-specific behavior are essential to avoid creating accounts with incorrect or incomplete profiles at login time.

Identity Governance Leads

Because JIT provisioning creates accounts on demand but generally does not handle deprovisioning, governance leads must plan for how accounts created at first login are reviewed, certified, and eventually removed. They should evaluate whether JIT alone meets lifecycle requirements or whether standards-based provisioning such as SCIM is needed for coordinated joiner-mover-leaver management.

Security Architects

Architects deciding between JIT provisioning and pre-provisioning approaches such as SCIM should weigh JIT's reduction in dormant accounts and manual effort against its dependence on identity-provider assertions and its lack of built-in deprovisioning. The choice affects the trust boundary and the accuracy of accounts across federated applications.

System Administrators and Application Owners

Those operating target applications that receive JIT-provisioned users need to know that accounts appear as a side effect of first authentication rather than through advance setup, and that update behavior on subsequent logins varies by product and configuration.

Inside JIT Provisioning

Federation-triggered account creation

In most JIT deployments, a user account is created in the target application or service provider at first successful authentication, rather than being pre-provisioned. The trigger is typically an incoming assertion or token during a federated SSO flow (for example a SAML 2.0 assertion or an OpenID Connect ID token).

Attribute and claim mapping

JIT relies on identity attributes conveyed at authentication time, such as SAML assertion attributes or OIDC claims, being mapped to local user profile fields. The completeness of the resulting account depends on which attributes the identity provider releases and how the relying party maps them.

Role and entitlement assignment at first login

Depending on configuration, JIT can assign roles or group memberships based on attributes present in the assertion (for example a group or role claim). This is an authorization concern derived from the authenticated identity, and the granularity available varies by vendor and by the access control model in use (for example RBAC or ABAC).

Relationship to SCIM provisioning

JIT is an alternative or complement to standards-based provisioning such as SCIM. SCIM typically pushes or synchronizes accounts ahead of use through a dedicated provisioning interface, whereas JIT creates or updates the account inline during the authentication event.

Update-on-login behavior

Many implementations refresh existing account attributes on each subsequent login when the identity provider supplies updated values, so JIT can cover ongoing attribute synchronization and not only initial creation, depending on configuration.

Common questions

Answers to the questions practitioners most commonly ask about JIT Provisioning.

Does just-in-time provisioning authenticate the user?

No. JIT provisioning is an account lifecycle and administration concern, not an authentication mechanism. It typically executes after a user has already been authenticated by an identity provider, for example, following a successful SAML 2.0 assertion or an OpenID Connect authentication flow. The provisioning step consumes the identity and attribute data that authentication produced; it does not verify who the principal is. Keep the sequence distinct: the user is identified and authenticated first, and only then does the relying party create or update a local account just in time.

Is JIT provisioning a replacement for SCIM?

Not exactly, and treating them as interchangeable blurs distinct capabilities. JIT provisioning typically creates or updates an account at the moment of login, driven by the assertion or token presented during a federated sign-in. SCIM is a dedicated provisioning protocol that supports proactive create, read, update, and deactivate operations independent of any login event. A common limitation of JIT is that it has no inherent mechanism to deprovision or disable accounts when a user should lose access, because it only acts when the user actively authenticates. Depending on your governance requirements, many deployments pair JIT for account creation with SCIM or another lifecycle process for deactivation and ongoing reconciliation.

Where does the attribute data for a JIT-provisioned account come from?

In most deployments, the local account is populated from the claims or attributes carried in the authentication response, for example, attribute statements in a SAML 2.0 assertion or claims in an OpenID Connect ID token. The relying party maps these incoming values to local user fields and, where applicable, to roles or group memberships. The completeness and accuracy of the provisioned account therefore depend on which attributes the identity provider is configured to release. Attributes not asserted at login are generally not available to the JIT process unless retrieved through a separate lookup.

How can access be revoked for accounts that were created through JIT provisioning?

Because JIT typically acts only during an active sign-in, it generally does not remove access on its own. Deprovisioning usually requires a complementary process, for example, SCIM deprovisioning, a scheduled reconciliation against an authoritative source, or an identity governance certification and access review workflow. Some deployments also mitigate stale access by disabling federation at the identity provider so the user can no longer authenticate, though the local account may persist until a separate cleanup runs. Plan deactivation explicitly rather than assuming JIT handles it.

How is role or entitlement assignment handled during JIT provisioning?

Role assignment during JIT is typically driven by mapping incoming assertion or token attributes to local roles or groups, which fits a role-based (RBAC) or attribute-based (ABAC) model depending on how the mapping is defined. The relying party's configuration determines whether asserted group values translate directly into local roles or feed into a policy decision. Note that this assignment is an administration-time mapping; it is separate from runtime authorization, where a policy decision point evaluates whether a given request is permitted. Keeping provisioning-time role assignment distinct from runtime enforcement helps avoid granting standing access that governance controls cannot later review.

What should be considered when handling repeat logins and attribute updates in JIT?

Implementations vary in whether JIT creates an account only on first login or also updates attributes on each subsequent authentication. Updating on every login can keep the local record synchronized with the identity provider, but it can also overwrite locally managed changes, so the desired precedence should be defined explicitly. Consider how the process matches an incoming identity to an existing account, commonly via a stable, non-reassignable identifier rather than a mutable value such as email, to avoid duplicate accounts or incorrect merges. These behaviors depend on vendor and profile configuration, so validate them against your specific deployment.

Common misconceptions

JIT provisioning authenticates the user by itself.

JIT is a provisioning mechanism that runs off the back of an authentication event; it does not perform authentication. The identity provider authenticates the user and the resulting assertion or token drives account creation. Identification, authentication, and provisioning remain distinct steps.

JIT provisioning fully replaces identity governance for the target application.

JIT handles runtime account creation and attribute population but does not by itself deliver IGA functions such as access certification, segregation-of-duties enforcement, or periodic access reviews. Governance over what those JIT-created accounts may do typically requires separate controls.

JIT and SCIM are interchangeable ways to do the same thing.

They differ in timing and mechanism. SCIM provisioning typically operates ahead of use through a dedicated provisioning API and can create, update, and deactivate accounts, including deprovisioning. JIT creates or updates accounts inline at login and, in most deployments, does not on its own handle deprovisioning when access should be removed.

Best practices

Treat JIT as provisioning only and keep it separate from your authentication decision: ensure the identity provider enforces the required assurance (for example MFA or step-up) so JIT does not create accounts from weakly authenticated sessions.

Pair JIT with a deprovisioning strategy, since JIT typically does not remove access on its own; use SCIM, scheduled reconciliation, or governance-driven reviews to disable or delete stale accounts.

Define explicit attribute-to-profile and claim-to-role mappings, and validate that the identity provider reliably releases every attribute the target relies on before granting entitlements.

Apply least-privilege defaults for JIT-created accounts and derive roles or entitlements from trusted, verified claims rather than granting broad access at first login.

Add governance controls such as access certification and segregation-of-duties checks over JIT-created accounts, because inline creation does not by itself provide review or attestation.

Log and monitor JIT creation and update events so first-login account creation is auditable, and reconcile them periodically against an authoritative source of identities.