Self Hosted Identity Provider
You set up a self hosted identity provider by running an auth server on your own hosts. Then you link your apps to this server using open login standards. Most teams group users into broad roles to speed up this rollout. Still, wide roles often give staff far more permissions than their daily tasks need. When one account gets compromised, an attacker inherits every single permission tied to that broad role. How a self hosted identity provider works A self hosted identity provider stores user
Self-Sovereign Identity + Identity Provider Integration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a self hosted identity provider by running an auth server on your own hosts. Then you link your apps to this server using open login standards. Most teams group users into broad roles to speed up this rollout. Still, wide roles often give staff far more permissions than their daily tasks need. When one account gets compromised, an attacker inherits every single permission tied to that broad role.
How a self hosted identity provider works
A self hosted identity provider stores user accounts and groups in a local database. You run the service on your own cloud hosts or private servers. Your team keeps full control over the user store and login logs. When an engineer opens an internal app, the app sends them to the login server. The engineer enters a password and passes a second factor check. Next, the server checks what group the engineer belongs to. The server signs a digital token that lists the user name and group roles. The app reads this token and lets the user in based on those roles.
Admins also link the server to existing user directories so staff keep one login. You can set rules for password length, token life, and step-up checks. When someone leaves the team, an admin turns off their account in one place. That single change blocks the person from signing into any linked app right away.
Planning user groups and role mapping
Clear role design keeps your setup easy to run over time. Teams usually start by matching groups to job titles like backend dev or data analyst. Each app reads the group claim from the login token to grant internal permissions. Problems start when an engineer needs temporary permissions to fix a broken production service. Admins often add that person to a high-level admin group during an outage. People rarely remove that extra group once the fire goes out. Over months, dozens of users collect permanent admin rights across critical systems. Reviewing group memberships every month helps you spot and remove stale permissions early.
What login servers solve and what they miss
Running your own login server solves the problem of scattered accounts and weak passwords. You gain a single place to enforce two-factor checks and check login history. It proves who a person is before they reach an internal tool. Yet the login server stops watching the moment the login handshake finishes.
Self-Sovereign Identity + Identity Provider Integration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
The server decides who logs in, not what commands or queries run during a session. Once a developer enters a database or server, the login tool is out of the loop. It cannot pause a dangerous delete command before the database runs it. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in query results. Teams still need controls that check each command and query in flight.
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 sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses 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 server instead of buying cloud tools?
Teams choose self hosting to keep user data on their own servers. It also avoids per-user cloud fees and works inside private networks without internet links.
What happens if the self hosted login server goes offline?
Users with active sessions can often keep working until their current tokens expire. Still, no one can start a new login until you run a backup server node.
Does a login server control what queries an engineer runs in a database?
No, the login server only checks identity and passes role claims at sign-in. It cannot inspect, block, or log individual SQL statements once the session starts.