In-house IdP
You build an in house idp by pairing a central user store with a token service. This service checks user passwords and issues signed login tokens to your internal apps. Teams often set this up to keep full control over user data and login rules. Still, teams often grant broad group roles to save time during the initial setup. Those wide permissions let one logged-in user touch too many databases and servers at once. How an in house idp works in practice A custom identity system relies on thre
Just-in-Time Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build an in house idp by pairing a central user store with a token service. This service checks user passwords and issues signed login tokens to your internal apps. Teams often set this up to keep full control over user data and login rules. Still, teams often grant broad group roles to save time during the initial setup. Those wide permissions let one logged-in user touch too many databases and servers at once.
How an in house idp works in practice
A custom identity system relies on three main parts to manage user logins. First, a directory database holds user names, password hashes, and group memberships. Second, a login server checks user credentials and runs multi-factor checks. Third, a token service creates signed tokens using open standards like OIDC or SAML.
When an engineer opens an internal tool, the app sends them to the login server. The engineer enters a password and approves a second factor on a phone or key. The identity server checks the directory to confirm the user is active and valid. Next, the server looks up the groups assigned to that user in the database.
The server packs these group names into a signed token and sends it back. The target app reads the signature using a public key from the identity server. If the signature matches, the app trusts the group claims inside the token. This flow lets teams manage one login record instead of separate accounts on every server.
Managing roles and group claims in your directory
Admins link directory groups to app roles so users get the right level of access. For example, a database group claim might map to a read-write role on a server. You must keep these group lists clean as people change jobs or leave the team. If an admin forgets to remove an old group, the user keeps those extra rights.
Token lifetime is another key setting that admins must tune with care. Long-lived tokens mean a user stays logged in even after you revoke their directory group. Short token lifetimes force apps to check back with the identity server more often. Teams also need backup servers in different regions so a crash does not lock everyone out.
Just-in-Time Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What a custom login server solves and what it misses
Building your own identity provider solves the problem of scattered passwords across your company. It gives you one place to turn off an account when an employee leaves. It also lets you enforce strong login checks across web apps and command-line tools. Your security team owns the login logs and does not pay per-user vendor fees.
Still, an identity server only checks who a person is at the moment they log in. Once the target database or server accepts the token, the identity system steps out. It cannot see the actual queries an engineer runs or the commands they type. A user with a valid role can still run a bad query that drops a table.
The login server also cannot mask sensitive fields like emails, phone numbers, or card numbers. If a role allows reading a table, the user gets every column in full text by default. To control actions after login, you have to inspect each command or query in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why do teams build an in house idp instead of buying one?
Teams build their own system to avoid high per-user costs and strict vendor limits. It also lets them keep all user records inside their own private network. Some teams need custom login flows that commercial tools do not support.
Which open standard should a custom identity system use?
Most modern teams choose OIDC because it works well with web apps and command-line tools. OIDC uses light JSON tokens that are easy for apps to read and check. Older enterprise apps may still need SAML, which uses larger XML messages for logins.
Does an identity provider control what queries a user runs?
No, an identity provider only confirms who the user is and shares their group roles. The target database or server decides what that role can do after login. Controlling specific queries or masking national IDs in results requires a separate check on the traffic.