In Keycloak, the process of logging in is never a single, fixed piece of code. Instead, it is modeled as an authentication flow — an ordered sequence of individual, swappable steps called executions. One execution might check a username and password. Another might send and verify a one-time code by SMS. Another might check whether the browser already has a valid session cookie, allowing it to skip straight through. Each of these executions is a small, self-contained unit that Keycloak can mix, match, and reorder to build very different login experiences without writing new code for each variation.

An execution requirement is the setting attached to each individual execution that tells Keycloak how important that step is, relative to the other steps around it, when the overall flow is evaluated for a real login attempt. There are three requirement levels you will use constantly, and a fourth, more advanced one worth knowing about:

Understanding execution requirements well means understanding the four pieces they interact with inside Keycloak’s authentication engine.

It helps to see a concrete, realistic flow layout. Keycloak’s default “browser” flow, in a typical realm, resembles something like this once expanded:

Notice something important in that example: the same word “Required” appears at two very different levels of nesting, and it means something slightly different each time depending on which group it belongs to. That nuance is exactly what the next chapter unpacks.

Keycloak’s authentication engine evaluates a flow by walking through its executions in order, top to bottom, applying a specific rule for each requirement level. Understanding these rules precisely — not just approximately — is the difference between designing a flow that behaves as intended and one that quietly locks users out or, worse, lets them skip a step they were supposed to complete.

Sub-flows add one more layer of subtlety worth calling out explicitly: a sub-flow’s own requirement level (Required, Alternative, Conditional, or Disabled) is evaluated from its parent flow’s perspective, exactly like any other single execution. But inside that sub-flow, its own child executions have their own independent Required/Alternative/Disabled settings, evaluated among themselves. This nesting is what allows Keycloak to express fairly sophisticated login logic — “always ask for a password, and then, only if the user has 2FA configured, ask for one of either an OTP code or a WebAuthn key” — using only these four simple settings, applied at different levels of the tree.

Tracing a single login attempt from start to finish makes the evaluation logic concrete.

flowchart TD
    A["Login attempt begins"] --> B["Cookie check
(Alternative)"]
    B -- Valid session found --> Z["Login succeeds
immediately"]
    B -- No session --> C["Identity Provider Redirector
(Alternative)"]
    C -- Redirect configured --> Y["Redirect to
external IdP"]
    C -- No redirect --> D["Browser Forms sub-flow
(Alternative)"]
    D --> E["Username Password Form
(Required)"]
    E -- Fails --> F["Login fails"]
    E -- Succeeds --> G{"OTP Conditional
sub-flow: condition met?"}
    G -- No, user has no OTP --> H["Flow complete
login succeeds"]
    G -- Yes, OTP configured --> I["OTP Form
(Required inside sub-flow)"]
    I -- Fails --> F
    I -- Succeeds --> H
    

Because execution requirements directly control how a user proves their identity, mistakes here have an outsized security impact compared to almost any other Keycloak setting.

Because flow configuration mistakes are silent by nature — a Disabled step does not throw an error, it simply stops running — observability is the main defense against them going unnoticed.

The idea of a configurable, step-by-step authentication pipeline built from mandatory and optional stages is not unique to Keycloak — it shows up, in different forms, across the identity industry.

Across all of these, the underlying pattern is the same: separate what must always be true from what is one acceptable option among several, and separate both of those from what should only apply in specific circumstances. Keycloak’s Required, Alternative, and Conditional levels are simply a direct, configuration-driven expression of that same widely-used idea.

Execution requirements are Keycloak’s way of turning a fixed login screen into a flexible, configurable checklist. Required steps are non-negotiable, Alternative steps offer a genuine choice among equals, Disabled steps are switched off entirely, and Conditional sub-flows apply their contents only when a specific circumstance is met. Together, these four simple levels — applied consistently across nested levels of a flow — let an administrator express surprisingly sophisticated authentication logic without writing a single line of custom code. The mechanics are simple once seen clearly; the discipline lies in testing every branch, naming things clearly, and treating changes to shared flows with the same care as any other security-critical configuration change.