User Controlled Identity
You set up user controlled identity by letting people manage their own login keys and claims. Each person holds a private key and approves which claims an app can read. Many teams build this setup to cut down on central password stores. Still, teams often attach broad backend roles to those verified profiles. Broad roles let one approved login touch too many tables or servers at once. How user controlled identity works in practice In a classic setup, a central directory owns every account and
Identity and Access Management (IAM) + User Provisioning (SCIM): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up user controlled identity by letting people manage their own login keys and claims. Each person holds a private key and approves which claims an app can read. Many teams build this setup to cut down on central password stores. Still, teams often attach broad backend roles to those verified profiles. Broad roles let one approved login touch too many tables or servers at once.
How user controlled identity works in practice
In a classic setup, a central directory owns every account and password. With user controlled identity, the person holds a digital wallet or hardware key. An issuer signs a claim that proves who the person is. The person stores that signed claim on their own device. When they log in, the app asks for proof of that claim.
The person signs a challenge with their private key and sends it back. The app checks the signature against the public key of the trusted issuer. If the check passes, the app maps that identity to an internal role. That internal role tells the database or server what the person can do. The person stays in control of when and where they share their profile.
What native identity setups solve and where they fall short
This model solves password theft and stops apps from hoarding personal profile data. Teams do not need to reset forgotten passwords or guard giant credential tables. It also gives people clear visibility into which apps ask for their info. Once the login check finishes, though, the app hands out a standard session role.
That role decides who logs in, not what each command does in flight. An engineer who proves their identity still gets a broad database or shell role. They can run a bad query that drops a table by mistake. A query can also return raw emails, phone numbers, or card numbers in results. Native identity checks stop at the front door and miss active commands.
Identity and Access Management (IAM) + User Provisioning (SCIM): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
How to pair identity checks with command level rules
To keep systems safe, teams must separate login proof from runtime command checks. First, keep your identity flow clean and verify only the claims you need. Map each verified person to a base group with zero standing write permissions. Next, inspect every query or shell command before the target system runs it.
When an engineer sends a write command, require a quick peer approval first. For read queries, apply data masking to rewrite matched fields in results. Masking turns sensitive emails, phone numbers, and national IDs into safe placeholders. This step keeps raw secrets out of local screens while work moves forward. You get strong user privacy at login and tight safety during every session.
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
What is the main benefit of user controlled identity for engineering teams?
It removes the need to store and guard user passwords in every app. People prove who they are with cryptographic keys they hold on their own devices.
Does a user controlled login stop someone from running risky database queries?
No, because login checks only verify who the person is at the start. You still need runtime checks to block bad queries and mask sensitive result fields.
How can teams protect sensitive data after a user logs in?
Teams can add command checks and data masking over their databases and servers. Masking rewrites matched fields like card numbers and emails in query results right away.