Just-in-Time Provisioning
A mechanism in SSO scenarios that automatically creates or links an account when a user logs in for the first time. Its core is resolving identity assertions in a fixed order and matching them against existing users.
Timeline (last 90 days)
Just-in-time provisioning is essentially a resolution order defined within the SSO callback, rather than a simple automatic account creation switch.
In the just-in-time provisioning resolution order, explicit bindings must take precedence over email matching, and an existing binding is the strongest signal.
After successful just-in-time provisioning, the binding between a stable identifier on the identity provider side (such as the OIDC sub or the SAML NameID) and the local user should be stored, to avoid re-matching by email on every login.
A common misconception is equating just-in-time provisioning with automatic registration; automatic registration should be a configurable policy rather than default behavior.
An implementation check should confirm three points: binding precedes email matching, email matching takes effect only when the identity provider states the email is verified, and the binding record includes the stable identifier and source information.
All Facts (5)
Just-in-time provisioning is essentially a resolution order defined within the SSO callback, rather than a simple automatic account creation switch.
50%UnverifiedIn the just-in-time provisioning resolution order, explicit bindings must take precedence over email matching, and an existing binding is the strongest signal.
50%UnverifiedAfter successful just-in-time provisioning, the binding between a stable identifier on the identity provider side (such as the OIDC sub or the SAML NameID) and the local user should be stored, to avoid re-matching by email on every login.
50%UnverifiedA common misconception is equating just-in-time provisioning with automatic registration; automatic registration should be a configurable policy rather than default behavior.
50%UnverifiedAn implementation check should confirm three points: binding precedes email matching, email matching takes effect only when the identity provider states the email is verified, and the binding record includes the stable identifier and source information.
50%