Self-hosted Identity Verification
You set up self hosted identity verification by running an open source login server. This server checks user keys and roles inside your own private network. Teams often build this setup to keep user data inside their own walls. They link a directory to an internal login app for all staff. Still, teams often grant broad roles so engineers can fix urgent bugs. Once a user logs in, those wide permissions let them run any command. How self hosted identity verification works in practice A self hos
Identity Verification (KYC) + Self-Sovereign Identity: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up self hosted identity verification by running an open source login server. This server checks user keys and roles inside your own private network. Teams often build this setup to keep user data inside their own walls. They link a directory to an internal login app for all staff. Still, teams often grant broad roles so engineers can fix urgent bugs. Once a user logs in, those wide permissions let them run any command.
How self hosted identity verification works in practice
A self hosted identity verification system runs on servers that your team controls. First, you pick a central directory to store user accounts and group names. Next, you deploy a login app that speaks standard web login protocols. When an engineer tries to log in, the app asks for a password. It also checks a second factor, like a hardware key or phone code.
After the check passes, the login server signs a digital token. This token holds the user name and their assigned team groups. The user sends this token to your internal databases and cloud servers. Each server checks the digital signature to make sure it is real. Then the server reads the group list and maps it to a role.
Your team must also manage the servers that run this login app. You need to back up the user database every single day. You also have to patch the host systems and rotate the signing keys. If the login server goes offline, nobody can log in to fix things. To avoid lockouts, teams run copies of the server across multiple zones.
What native login checks solve and what they miss
Running your own login system gives you full control over user records. You do not have to send staff names to an outside vendor. Your security team decides how often users must log in again. You also get a single place to turn off an account fast. When someone leaves the team, you block their login in one spot.
Still, a login check only decides who can open the front door. It does not watch what the user does after the session starts. Once a database accepts the user role, that role stays active for hours. A developer with write permissions can drop a table by mistake. They can also run a big query that pulls every customer phone number.
Identity Verification (KYC) + Self-Sovereign Identity: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The login server cannot see individual database queries or shell commands in flight. Its logs only show that a user logged in at nine in the morning. They do not show what records the user read five minutes later. When an audit happens, your team must dig through many separate server logs. Even then, local server logs rarely link each query back to one person.
Closing the gap between login and live commands
To reduce risk, teams try to split big roles into many small ones. They make one role for reading tables and another for writing data. Soon, the team has hundreds of roles to track and update by hand. Engineers get stuck waiting for someone to grant a role for basic work. Out of frustration, admins end up handing out broad admin roles again.
Real security requires checking actions at the moment a user runs a command. Instead of trusting a whole session, you need rules for each action. You also need a way to mask sensitive fields like card numbers. Masking rewrites matched fields in results before they reach the user screen. This keeps private data safe while letting engineers do their daily work.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do teams run their own login servers instead of cloud tools?
Teams run their own servers to keep full control of user data. Some strict rules forbid storing staff records on outside cloud systems. A local setup also works inside private networks with no internet link.
What happens if a self hosted login server goes down?
If the server fails, users cannot start new sessions on internal tools. Active sessions might keep working until their current login tokens expire. Teams run backup nodes in separate zones to prevent a total lockout.
Does identity checking stop an engineer from deleting production data?
No, a login check only proves who the person is at login time. If their assigned role allows writes, they can still delete production data. Stopping bad commands requires checking each action after the session begins.