Self Hosted 2FA
You set up self hosted 2fa by running your own token server and linking it to your login system. This setup forces every user to enter a second code before they log in. Many teams deploy a local token app to keep user keys inside their own network. Still, passing a login check often grants wide role permissions across databases and servers. Once a user logs in, broad roles let them run risky commands without further checks. How a self hosted 2fa workflow operates A self hosted 2fa system runs
Self-Service Access Portals: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up self hosted 2fa by running your own token server and linking it to your login system. This setup forces every user to enter a second code before they log in. Many teams deploy a local token app to keep user keys inside their own network. Still, passing a login check often grants wide role permissions across databases and servers. Once a user logs in, broad roles let them run risky commands without further checks.
How a self hosted 2fa workflow operates
A self hosted 2fa system runs on servers that your own team manages. First, an admin installs an open source identity app or a local token service. Next, the admin links this service to the main user directory. When a team member adds an account, the server shares a secret key. The user saves this key in a phone app or on a hardware key.
During login, the user types a password and a six-digit code. The local server checks the password against the user directory first. Then the server checks the code against the stored secret key and current time. If both checks pass, the system creates a valid session for the user. Your team keeps full control over the user database and the secret keys. No outside vendor holds your login data or processes your user checks.
What native login checks solve and what they miss
Running your own second factor server stops stolen passwords from working on their own. Attackers cannot log in if they only have a leaked password from a phishing attack. It also helps teams meet strict rules that forbid third-party cloud login tools. Your login system stays up even when outside cloud services go down.
Still, a login check only decides who enters the network at the start. It does not inspect what a user does after the session begins. A developer who passes the login check might still hold a broad database role. That developer can run a query that reads raw phone numbers or card numbers. They can also drop a table by mistake during a routine fix. Standard login tools cannot pause a dangerous command or ask a peer for approval. They also cannot rewrite sensitive fields like emails or national IDs in query results. To control live actions, teams need controls that work at the command level.
Self-Service Access Portals: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing secret keys and backups on your own servers
When you run your own token server, you must guard the secret database. Every user token relies on a shared secret stored on your local disk. If an attacker reads that disk, they can copy every user token. Your team must encrypt those stored secrets with a strong master key. You also need to store that master key on a separate host.
Hardware failures create another major risk for local login systems. If your single token server crashes, nobody on the team can log in. Admins must run at least two token servers in different server racks. You also need a clear way to reset tokens when someone loses a phone. Without a safe reset rule, help desk staff might hand out codes to attackers.
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
What happens if our local token server loses time sync?
Time-based codes fail if your server clock drifts away from the real time. You must point your server at a trusted time source so codes match user phones.
Can we use hardware keys with a local login server?
Yes, most local identity tools support physical security keys through standard web protocols. Hardware keys resist phishing better than typed six-digit codes because they check the domain name.
Does a second login factor control database queries after login?
No, a second factor only checks identity at the start of a session. You need separate command controls and data masking to limit what logged-in users can run.