Before touching Keycloak’s screens, let’s fix the plain-English idea in place.

Just-in-Time Provisioning is the practice of creating a user’s account record automatically, at the exact moment they first authenticate, rather than requiring someone to create that account beforehand through a separate administrative process. In Keycloak, this most commonly happens in two situations: when a user logs in for the first time through a brokered Identity Provider (like a corporate SSO system or a social login), and when a user authenticates against an external directory through User Federation (like LDAP) configured in import mode.

In both cases, the underlying idea is the same: Keycloak trusts that the external system has already verified who this person is, so instead of asking an administrator to separately go create a matching local record, it builds — or refreshes — that record itself, using the attributes handed back by the external system at login time.

Understanding the problem it solves makes the whole feature click into place.

Manually provisioning every user account ahead of time works fine for small, stable populations of users. It quickly becomes painful at scale — think of an organization onboarding thousands of employees from a corporate directory, or a public-facing application expecting an unpredictable stream of new sign-ups through social login. Pre-creating every possible account either requires constant administrative effort to keep synchronized, or simply isn’t practical when the exact set of future users isn’t known in advance.

JIT provisioning sidesteps that problem entirely: there’s nothing to pre-create, and nothing to keep manually synchronized as the underlying population changes. The account simply appears — accurately reflecting the external source — the very first time it’s actually needed, and can keep refreshing itself on every subsequent login.

JIT is one of several ways user accounts can end up inside Keycloak — it helps to see it alongside the alternatives.

Keycloak doesn’t force an all-or-nothing choice between these. It’s common for an organization to use JIT for the everyday flow of new users logging in for the first time, while still occasionally relying on bulk imports or manual creation for special cases, like service accounts or accounts that need to exist before anyone has actually logged in.

JIT provisioning in Keycloak happens through two related, but distinct, mechanisms.

Both paths share the same underlying philosophy — trust an external source, and build the local record from it, exactly when it’s first needed — but they differ in what triggers them and where the “source of truth” for future attribute updates lives afterward.

This is the path most people mean when they talk about JIT provisioning in Keycloak.

When a user authenticates through a brokered Identity Provider for the very first time, and no existing federated identity link is found, Keycloak’s First Broker Login flow kicks in. Depending on how that flow is configured, it can automatically create a new local user, pre-filling attributes like name and email straight from the claims the external provider returned — all without an administrator ever touching the admin console.

flowchart LR
    A["User logs in via
Identity Provider (first time)"] --> B{"Federated Identity
Link exists?"}
    B -- No --> C["First Broker Login Flow"]
    C --> D["Create local user
from provider claims"]
    D --> E["Identity Provider Mappers
set attributes/roles/groups"]
    E --> F["Local session issued"]
    B -- Yes --> F
        

The second common path runs through Keycloak’s directory integration rather than a login-page redirect.

When an LDAP-backed User Federation provider is configured with the Import edit mode, the first time a user successfully authenticates against that directory, Keycloak copies the relevant LDAP attributes into a local user record inside its own database. On future logins, Keycloak re-validates the password against LDAP again, and can refresh the cached local attributes to stay in sync with any changes made in the directory.

Here’s the sequence of events for a brand-new user’s very first login, brought together in one place.

JIT provisioning doesn’t stop at account creation — it can keep refreshing details on every subsequent login too.

Both brokering-based and LDAP-based JIT flows can be configured to re-apply mappers on every login, not only the very first one. That means if a user’s job title changes in the corporate directory, or their department claim changes at the external Identity Provider, the next time they log in, Keycloak can automatically update the corresponding local attribute, role, or group membership to match.

Zooming out to see how a JIT-provisioned account behaves across its whole lifetime, not just at creation.

sequenceDiagram
    participant U as User
    participant K as Keycloak
    participant Ext as External System (IdP / LDAP)

    U->>K: First login attempt
    K->>Ext: Authenticate / verify identity
    Ext-->>K: Success + attributes
    K->>K: No local user found — create one
    K-->>U: Session issued (account now exists)

    Note over U,Ext: Time passes — attributes change externally

    U->>K: Later login
    K->>Ext: Authenticate again
    Ext-->>K: Success + updated attributes
    K->>K: Refresh existing local user's attributes
    K-->>U: Session issued (account now up to date)
        

JIT provisioning is excellent at creating and updating accounts — it’s worth being honest about what it doesn’t automatically handle.

Because a JIT-provisioned account is only ever touched when its owner logs in, there’s a natural gap: if a user is removed from the external directory or Identity Provider but never logs in again, their local Keycloak account can simply sit there, unchanged, since nothing triggers an update for a login that never happens. This is sometimes called the “deprovisioning gap,” and it’s a well-known limitation of purely login-triggered provisioning.

Automatically creating accounts based on external input is convenient, but it deserves the same scrutiny as any other trust boundary.

JIT provisioning trades some control for a lot of operational simplicity.

A few recurring habits separate smooth JIT rollouts from confusing ones.

A short, practical checklist for teams enabling JIT provisioning for the first time.

JIT provisioning shows up anywhere the exact set of future users isn’t fully known in advance.

Because JIT provisioning creates accounts silently, having visibility into what’s happening matters.

Not exactly. It’s the natural result of how Identity Brokering’s First Broker Login flow and LDAP User Federation’s import mode already behave — there’s no single dedicated “JIT” toggle.

Yes. Since JIT provisioning through brokering is a property of the First Broker Login flow, it applies regardless of whether the underlying Identity Provider uses OIDC or SAML.

The local Keycloak account remains as-is; JIT provisioning doesn’t automatically detect or react to removal at the external source, which is why a separate deprovisioning process is important.

Yes. Once created, it’s a normal local Keycloak user and can be edited like any other account, though changes may be overwritten later if attributes are configured to sync on every login.

It can be, but typically only when paired with a proper offboarding and audit process, since regulated environments usually require timely, verifiable access removal that JIT alone doesn’t provide.

No. Since authentication is delegated to the external source, JIT-created accounts typically don’t get a local password at all — they continue authenticating through the same external system going forward.

Just-in-Time Provisioning is Keycloak’s way of building — and optionally continuing to refresh — a local user account automatically, exactly at the moment it’s first needed, rather than requiring it to be created in advance. It shows up naturally through Identity Brokering’s First Broker Login flow and through LDAP User Federation running in import mode, both of which trust an external source enough to build a local record straight from its attributes. Used thoughtfully — with tightly scoped default access and a real plan for offboarding — JIT provisioning removes a huge amount of manual account-management overhead, at the cost of needing a deliberate answer for what happens when someone eventually leaves the external source behind.