Self Hosted Auth
You set up self hosted auth by running an open identity server on your hardware. This server checks user logins and hands out signed tokens to your internal apps. Most teams start this setup to keep full control over user records and keys. They map team groups to broad app roles so people can work fast. Still, broad roles often give users far more power than their daily tasks require. How a self hosted auth setup works A self hosted auth server acts as the main login desk for your systems. Fi
Self-Service Access Portals + Network Location-Based Auth: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up self hosted auth by running an open identity server on your hardware. This server checks user logins and hands out signed tokens to your internal apps. Most teams start this setup to keep full control over user records and keys. They map team groups to broad app roles so people can work fast. Still, broad roles often give users far more power than their daily tasks require.
How a self hosted auth setup works
A self hosted auth server acts as the main login desk for your systems. First, you pick an open engine that fits your stack and run it. You pair this engine with a private database to hold user accounts and keys. Next, you link your internal apps to this central login server using standard protocols. When an engineer tries to log in, the app sends them to your server. The server checks their password and asks for a second code from their phone. Once the check passes, the server creates a signed digital token for that user. This token holds the user identity and a list of their assigned team roles. The user sends this token back to the app to prove who they are. The app reads the signature on the token using a public key. If the signature is valid, the app lets the user in right away. You can also link your server to an existing company directory to sync accounts. This stops your team from making new accounts by hand for every new hire. Admins manage all these rules from one control panel on your private network.
Why teams run their own login servers
Teams choose to run their own login servers for privacy and cost reasons. Cloud login vendors often charge high fees as your user count grows each month. They may also charge extra for basic features like single sign-on or audit logs. When you run the software yourself, you only pay for the base compute servers. You also keep all sensitive user data inside your own private network boundary. No outside vendor holds your password hashes, session records, or private signing keys. This helps teams meet strict data rules that ban storing user records in public clouds. You also control when to update the software and how long to keep logs. If a cloud vendor goes down, your team can still log in and work. You are not tied to the uptime or price hikes of an outside company.
What native login servers leave open
Running your own login server solves the problem of checking who a user is. It proves a person belongs to your team before they open an internal app. Still, a login server only acts at the front door of your systems. Once the user gets a valid token, the auth server steps out of the way. It cannot see the actual commands or database queries the user runs next. Most teams map identity groups to wide database or server roles to save time. An engineer might log in with a valid token and get full write power. The login server has no way to stop that user from dropping a table. It also cannot rewrite sensitive fields like emails, phone numbers, or card numbers in results. The native setup decides who logs in, not what individual requests do in flight. Also, your apps still need local roles and static keys to talk to databases. Managing these local roles across dozens of databases quickly becomes a huge chore. If an attacker steals a valid session token, they gain all that broad power. You have a log showing the user logged in, but no log of their actions.
Self-Service Access Portals + Network Location-Based Auth: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
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
How do we keep a self hosted auth server safe from outages?
You should run at least two copies of the server behind a load balancer. Pair them with a database that writes copies of data across multiple zones.
Can a self hosted auth setup stop a user from running bad queries?
No, a login server only checks who you are at the start of a session. It does not read or block the specific database queries you run after login.
How should we store the signing keys for our login server?
Keep your private signing keys in a dedicated hardware module or encrypted secret store. Never save raw signing keys in plain text files on the server disk.