Just-in-time Provisioning
You set up just in time provisioning by linking your identity tool to target apps. The target app then creates a local user account when someone logs in. Engineering teams use this method so they do not make accounts by hand. They map identity groups to app roles during the initial login flow. If those roles are too broad, every new user gets too much power. How just in time provisioning works at login The workflow starts when an engineer tries to log in to a system. The target app sends the
Just-in-Time Access + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up just in time provisioning by linking your identity tool to target apps. The target app then creates a local user account when someone logs in. Engineering teams use this method so they do not make accounts by hand. They map identity groups to app roles during the initial login flow. If those roles are too broad, every new user gets too much power.
How just in time provisioning works at login
The workflow starts when an engineer tries to log in to a system. The target app sends the user to a central identity provider first. The user proves who they are with a password and a second factor. Next, the identity provider builds a signed token for the target app. This token holds user facts like an email address and group names. The user browser sends this signed token back to the target app.
The target app checks the signature on the token to trust the sender. It reads the email address and looks for an existing local user account. If no account exists, the app creates a new one right away. It reads the group names in the token to pick a local role. The app assigns that role to the new account and starts the session. On later logins, the app can update the role if groups change.
How teams map identity groups to local roles
Teams must match central identity groups to local roles inside each target system. A database or cloud console needs to know what a group name means. Admins set up rules inside the target app to handle this mapping. For example, a developer group might map to a read and write role. An analyst group might map to a basic read-only role instead.
Keeping these role rules clean across many apps takes a lot of work. Teams often take shortcuts and create a few large groups for everyone. They map an entire engineering group to a high admin role by mistake. When a new hire logs in, the app gives them full admin rights. The account also stays active inside the app long after the session ends.
What native account creation solves and what it misses
This login method saves hours of manual setup work for system admins. New team members get the accounts they need on their very first day. Admins do not need to type names and emails into twenty different tools. Central identity groups become the single source of truth for who gets in.
Just-in-Time Access + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Still, account creation only decides who can log in to a tool. It does not control what a user does after the session starts. Once an account exists, it holds standing power until another sync removes it. If an identity tool only creates accounts at login, offboarding gets tricky. A fired user cannot log in through the identity tool anymore. Yet their local account and active keys might still work inside the app.
More importantly, a static role cannot check individual commands or queries in flight. A user with a valid role can still run a bad delete query. They can also pull thousands of customer emails and card numbers at once. Native account creation stops at the front door and misses live session actions.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How does just in time provisioning differ from SCIM?
The login method creates or updates an account only when a user signs in. SCIM runs in the background to create, update, and delete accounts at any time.
What happens when a user leaves the company?
Blocking the user in the identity tool stops new logins right away. Still, the local account stays in the target app unless you run SCIM too.
Can this login method protect sensitive data inside a database?
No, it only creates the user account and assigns a broad database role. You need query controls and data masking to rewrite emails or card numbers in results.