Keycloak MFA
You set up keycloak mfa by adding a second check to your login flow. Users then type a password and a one-time code to log in. Engineering teams use this setup to guard internal apps and tools. Still, broad user roles still let people run risky commands after they log in. How keycloak mfa works in your login flow Keycloak checks who a user is through a step-by-step login flow. Each step in this flow asks the user for one piece of proof. The first step checks a username and password against yo
Keycloak: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up keycloak mfa by adding a second check to your login flow. Users then type a password and a one-time code to log in. Engineering teams use this setup to guard internal apps and tools. Still, broad user roles still let people run risky commands after they log in.
How keycloak mfa works in your login flow
Keycloak checks who a user is through a step-by-step login flow. Each step in this flow asks the user for one piece of proof. The first step checks a username and password against your user store. The second step asks for a temporary code or a hardware key tap.
Admins can require this second step for everyone in a realm. They can also require it only for specific user groups or roles. When a user logs in for the first time, the server shows a setup screen. The user scans a barcode with a phone app and types the six-digit code. Future logins ask for a fresh code from that same phone app.
Teams can also link external directories like Active Directory or LDAP to their realm. In that case, the directory checks the password first. Then the realm runs the second check before it issues a login token. The user gets a signed token and sends it to the target app.
Choosing factors for different engineering roles
Not every role needs the same type of second factor. Standard phone apps generate time-based codes that work well for most daily tasks. These codes change every thirty seconds and do not need an internet connection. Still, attackers can still trick users into typing these codes on fake login pages.
Hardware security keys offer stronger protection for prod admins and on-call engineers. These keys use browser standards to check the exact website domain before they sign in. If a user visits a fake page, the hardware key refuses to send the proof. Admins can set up the login flow to accept both phone codes and hardware keys. Users with higher privileges must register a hardware key before they can log in.
Keycloak: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native login checks solve and what they leave open
A strong login flow stops attackers who steal or guess a user password. It proves that the right person sits at the keyboard when the session starts. It also gives security teams a clear log of who signed in and when. This meets basic audit rules for user sign-in across your company.
Still, the identity server steps out of the way once the session starts. It hands out a token and does not watch what happens next. If an engineer logs into a database tool, the identity server cannot see the queries. A user who passed the login check can still drop a table by mistake. They can also pull sensitive fields like emails, phone numbers, card numbers, or national IDs.
Shared database accounts make this gap even wider for engineering teams. Even if users sign into a dashboard with two factors, the backend often uses one shared role. Audit logs on the database server only show that shared role name. Teams lose track of which person ran a specific query or command. Login checks verify who enters the room, but they do not control actions 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
Can I require a second factor only for specific groups?
Yes, you can add a conditional step inside your login flow. That step checks if the user belongs to a specific group or role before asking for a code.
What happens when an engineer loses their phone or hardware key?
An admin can reset the stored credentials for that user account. The user must then register a new device during their very next login.
Does a login check protect database queries after sign-in?
No, the identity server only checks who logs in at the start. It does not inspect, block, or mask individual queries or commands during the session.