Just-in-time provisioning means creating the account at the moment of first sign-in, out of the attributes the assertion carried. It costs almost nothing to build — you already parse those attributes — and it solves the visible half of the problem immediately. Nobody has to be invited, nobody waits for an administrator.
SCIM means the customer's directory tells you about people directly, whether or not they ever sign in. It is more work on both sides, and it answers a question JIT structurally cannot.
What JIT cannot see
A JIT-provisioned account only ever changes when its owner signs in. If somebody leaves the company on Friday, your record still says active on Monday, and it will keep saying active for as long as they never come back. Nothing arrives to tell you otherwise, because the only channel you have is a person walking through the door.
In practice the identity provider does block their sign-in, so they cannot get in through the front. But your database still lists them as a member with a role, they still appear in seat counts and mention menus, their API tokens still work if you issue any, and the answer to how quickly you can revoke access is that you cannot, because you were never told.
JIT knows who arrived. It has no way to learn who left, because leaving produces no sign-in.
Where each one is the right answer
JIT is right when accounts are cheap, membership is not sensitive, and the sign-in path is genuinely the only way in. It is also the pragmatic choice for a customer whose directory cannot speak SCIM at all, which is more of them than vendor documentation suggests.
SCIM is right when access has to be provably removable, when people need to exist before they arrive — a mailbox, an assignment, a pre-provisioned workspace — or when group membership drives permissions. It is also what a security reviewer means when they ask about deprovisioning, and answering with JIT will not satisfy them.
- JIT: fast to build, no administrator setup, no view of leavers
- SCIM: joiners, movers and leavers, group membership, seat accuracy
- Running both is normal — SCIM as the source, JIT as the fallback for gaps
- If you run both, one of them must win on conflict, and it should be SCIM
Running them together without a mess
The combination that works treats SCIM as authoritative and JIT as a safety net. When an assertion arrives for somebody you do not hold, create them — a person standing at the door with a valid credential should not be turned away because a sync is behind. But mark the record as JIT-created, and let the next SCIM reconciliation adopt or deactivate it.
Store the provider's identifier from both channels so the two views can be joined. Matching on email works until somebody changes their name, at which point you have two records for one person and no way to tell which one carries their history.
Everything here, already built
Sign-in, enterprise SSO, directory provisioning, roles and an audit trail behind one API. Start with the quickstart and have a working sign-in this afternoon.