Self Hosted Auth Server
You set up a self hosted auth server by running an identity service on your own servers. This server checks user logins and issues signed tokens to your internal apps. Engineering teams use this setup to keep user data inside their own network. Still, broad roles often give users too much power once they log in. When a role has wide permissions, one mistake can break a live system. How a self hosted auth server works in practice A self hosted auth server acts as the single source of truth for
Self-Service Access Portals + Kubernetes API Server Access: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a self hosted auth server by running an identity service on your own servers. This server checks user logins and issues signed tokens to your internal apps. Engineering teams use this setup to keep user data inside their own network. Still, broad roles often give users too much power once they log in. When a role has wide permissions, one mistake can break a live system.
How a self hosted auth server works in practice
A self hosted auth server acts as the single source of truth for user identities. First, an admin sets up the server and links it to a local database. This database stores user accounts, password hashes, and group memberships in one place. Next, the admin registers each internal app or tool as a trusted client. Each client gets a unique ID and a secret key to verify its identity.
When an engineer tries to log in, the app redirects them to the auth server. The server checks their password and asks for a second factor, like a mobile code. After the check passes, the server builds a signed token with the user role inside. The app reads this token and lets the user in based on that role. Teams often map these roles to groups like backend devs, data analysts, or support staff.
What native identity roles solve and what they miss
Running your own identity server solves several big problems for an engineering team. You keep full control over user records and login logs on your own disks. You also avoid sending private team data to an outside vendor on the public web. If the outside internet goes down, your local team can still log in and work. It also lets you enforce strict password rules and multi-factor checks for everyone.
Yet this setup only decides who can open the door to a system. Once a database or server accepts the login token, the auth server steps aside. It does not watch what commands or queries the user runs inside that session. If a developer logs in with a write role, they can drop a table by mistake. They can also read raw emails, phone numbers, card numbers, or national IDs in full.
Self-Service Access Portals + Kubernetes API Server Access: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why teams need finer control over live sessions
Standard auth groups are too blunt for daily work on live production systems. Teams usually create a few broad roles so they do not drown in admin tickets. A developer needs write rights for one small fix, so they get a full admin role. That role stays active for hours or days, long after the fix is done. Shared database accounts make this worse because logs only show the shared account name.
To stay safe, teams must inspect actions at the command and query level. Security does not end when the login check finishes and the session starts. You need a way to review risky commands before they hit your core data. You also need data masking that rewrites matched fields in results during live queries. Combining strong login checks with runtime controls closes the gap between login and execution.
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 runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why do teams run a self hosted auth server instead of a cloud service?
Teams run their own server to keep full control over user identity data and logs. It also lets internal apps work on closed networks without public internet links.
Does an auth server control what queries a user runs in a database?
No, an auth server only checks who the user is during the initial login step. Once the database session starts, the database handles permissions and the auth server stops watching.
How can teams protect sensitive fields like card numbers after a user logs in?
Teams add runtime controls that check queries and apply data masking on the fly. Data masking rewrites matched fields in results, such as emails, phone numbers, and national IDs.