Self-hosted MFA
You set up self hosted mfa by running an identity server on your own hosts. This server checks a second factor after a user types a password. Most teams link this login service to their apps, servers, and databases. That check confirms who starts the session. Still, broad roles still let logged-in users run any command inside the system. If an account has wide rights, a second login step will not restrict bad queries. How self hosted mfa works in your stack A local identity server runs inside
Self-Service Access Portals: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up self hosted mfa by running an identity server on your own hosts. This server checks a second factor after a user types a password. Most teams link this login service to their apps, servers, and databases. That check confirms who starts the session. Still, broad roles still let logged-in users run any command inside the system. If an account has wide rights, a second login step will not restrict bad queries.
How self hosted mfa works in your stack
A local identity server runs inside your private network or virtual cloud. It stores user profiles, device keys, and token seeds in a local database. When an engineer logs in, the target system asks the identity server for approval. The user first gives a username and a password.
Next, the server asks for a second proof of identity. This proof can be a six-digit code from a phone app. It can also be a tap on a hardware security key. The local server checks this code against the stored seed or public key. If the check passes, the server issues a signed token for that user.
Teams link this flow to Linux hosts, Kubernetes clusters, and Postgres databases. For Linux servers, a pluggable login module talks to the identity server during SSH login. For web apps and clusters, open protocols pass the signed token back to the client. Everything stays inside your network, so login checks work even when public cloud services fail.
What local second-factor checks solve and what they miss
Running your own second-factor service stops stolen passwords from working on their own. Attackers with a leaked password still face a wall at the login screen. You also keep full control over user secrets and login logs. No third-party vendor holds your token seeds or device keys.
Yet this login check only guards the front door of your system. Once the user passes the prompt, the session starts with full role rights. The identity server does not see what happens inside the database or shell session. A developer with write access can drop a table or update every row.
Shared database accounts make this gap even wider for ops teams. Many database engines cannot prompt for a code inside a standard client tool. Teams often place the second factor on a network tunnel instead. Once inside the tunnel, everyone uses the same broad database login. You know who opened the tunnel, but not who ran a destructive query.
Self-Service Access Portals: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Raw query results also flow back to the client without any filter. If a table holds emails, phone numbers, card numbers, or national IDs, the user gets all of them. A login check cannot rewrite sensitive fields in query results. It also cannot pause a risky command for peer approval before it runs.
Closing the gap between login and live commands
Strong security needs checks during the session, not just at login time. Teams should tie every single query and shell command to one person. Instead of handing out long-lived database passwords, keep target secrets away from client machines. Engineers should log in with their own identity and get scoped rights for each task.
When a high-risk command runs, the system should ask a teammate to approve it. This step acts like a second factor for the specific action itself. Data masking can also rewrite emails and card numbers in query output on the fly. Combining login checks with command controls protects both the front door and the data inside.
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
Can I use hardware keys with a local MFA server?
Yes, most open identity servers support hardware security keys through modern web standards. Users register their physical key once and tap it during future logins.
How do teams handle database tools that lack MFA prompts?
Standard database drivers only expect a username and password during the initial handshake. Teams usually handle the login flow through a CLI wrapper before opening the database client.
What happens if the local identity server goes offline?
If a single identity host fails, users cannot start new sessions on protected systems. Teams run at least two server nodes behind a load balancer to prevent lockouts.