Keycloak Login Flow
You set up a keycloak login flow by chaining login steps inside a realm. Each step checks a password, token, or device before granting a user session. Platform teams often reuse one default flow for all internal apps and databases. This broad setup gives users wide roles that stay active for hours. How the keycloak login flow works A realm holds the rules for how users sign in to your apps. When a user tries to log in, the server starts a sequence of steps. Each step in the sequence is an exe
Keycloak + Data Flow Diagrams (Security): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a keycloak login flow by chaining login steps inside a realm. Each step checks a password, token, or device before granting a user session. Platform teams often reuse one default flow for all internal apps and databases. This broad setup gives users wide roles that stay active for hours.
How the keycloak login flow works
A realm holds the rules for how users sign in to your apps. When a user tries to log in, the server starts a sequence of steps. Each step in the sequence is an execution that checks one specific thing. The first step usually checks an active browser cookie from a past login.
If no valid cookie exists, the flow moves to the next form step. The user then enters a username and password on the hosted login page. You can mark each step in the flow as required, alternative, or disabled. A required step must pass for the login to move forward at all.
An alternative step lets the user pick one login method out of several options. For example, a user might pick a passkey instead of a password and code. You can also nest sub-flows to group multiple steps under one conditional branch. Conditional branches run only when a user matches a specific role or network rule.
After all required steps pass, the server runs post-login actions for that user. These actions force the user to update an old password or set up MFA. Last, the server maps group memberships and roles into a signed token. The client app reads this token to see who the user is today.
Choosing between browser and direct grant flows
Not every login uses a web browser to show forms to a person. The browser flow handles human users who click through web forms and MFA prompts. It relies on HTTP redirects between the client app and the identity server. This setup keeps user passwords away from the client app code.
Command line tools and scripts often use a direct grant flow instead. In a direct grant, the client sends credentials straight to the server API. This skips browser redirects, which breaks many web-based MFA prompts and hardware keys. Teams should disable direct grants unless a legacy tool requires that exact path.
Keycloak + Data Flow Diagrams (Security): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
You can also build a reset credentials flow for users who forget passwords. This flow sends an email link and checks a second factor before resetting. Keeping this flow strict stops attackers from taking over accounts through weak recovery steps. Every flow in your realm needs the same level of MFA enforcement.
What the login flow solves and what it leaves open
A well-built login flow proves who a person is before they enter your network. It centralizes password rules, multi-factor prompts, and single sign-on across your whole team. When someone leaves the company, you revoke their account in one central place. This stops unauthorized people from getting new tokens for your internal tools.
Still, the login flow only controls the front door to your systems. Once the server issues a token, its job in the session is done. The identity server cannot see what SQL queries or shell commands the user runs. If an engineer gets a database role, they can run destructive queries right away.
Static roles in tokens also fail to protect sensitive data inside database tables. A valid login lets a developer query raw emails, phone numbers, and card numbers. You need runtime controls to inspect commands and mask fields like national IDs in results.
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
What is the difference between a required and an alternative step?
A required step must succeed for the user to finish logging in. An alternative step succeeds if at least one option in that group passes.
Can I assign a custom keycloak login flow to a single client app?
Yes, you can override the default realm flow inside an individual client setup. This lets you enforce stricter MFA rules for sensitive apps without changing others.
Why should teams edit a copy of the default login flow?
Editing a built-in flow directly makes it hard to recover if you lock yourself out. Cloning the flow first gives you a safe backup to restore at any time.