JIT Provisioning

How it works

JIT (Just-in-Time) Provisioning creates a user account in your app at the moment of first login, not before. When an SSO assertion or OIDC token arrives from the identity provider, the app reads the claims (name, email, group membership) and creates or updates the local user record on the spot, then maps IdP groups to app roles. SAML supports this through attribute statements in the assertion; OIDC supports it through ID token claims. No admin ever ran an "add user" script; the first successful login is the provisioning event.

When it matters

JIT provisioning matters the moment you turn on SSO, because it is what lets a new hire log in on day one without an admin manually creating their account first. It is the default assumption of most SAML and OIDC integrations, and skipping it means someone on your team is stuck pre-creating accounts before every login, which does not scale past a handful of customers. It is not a substitute for lifecycle management: JIT creates and updates accounts, but it does not deactivate them when someone leaves, which is what SCIM is for. See Add SSO to Your B2B SaaS and SCIM Provisioning Guide.

Common misconceptions

• "JIT provisioning replaces SCIM." JIT only creates and updates accounts on login. It has no way to know a user was disabled in the IdP if that user never logs in again, so stale accounts pile up. SCIM handles deprovisioning; JIT does not.
• "JIT is a security downgrade because it creates accounts automatically." The account only gets created after a valid, signed assertion from a trusted IdP. That is not weaker than manual provisioning, it is faster and removes the human error of a stale admin panel.
• "You need a big IAM project to support JIT." Reading claims off a SAML assertion or OIDC token and upserting a row is a few hours of engineering work for most apps, not a quarter-long initiative.