Learn Authentik - Understanding Flows & Stages

#Introduction

Now that Authentik is running from episode 3 and you've logged into the admin interface as akadmin, it's time to get to know the concept that most distinguishes Authentik from other identity providers: flows & stages. If your stack isn't running yet, start it first with docker compose up -d.

In Authentik, almost everything you see is a flow: login is a flow, registration is a flow, password reset is a flow, logout is a flow, even MFA setup is a flow. There's no hard-coded static login page — everything is built from small blocks called stages assembled by the flow executor. Like an assembly line in a factory: each stage is one workstation, and the flow is the sequence of stations that determines the final outcome.

#Flow Fundamentals

#Designation

Every flow has a designation — the purpose marker that determines when Authentik invokes it. When a user needs to log in, Authentik looks for a flow with the authentication designation; when a password reset is needed, it looks for a flow with the recovery designation. The available designations: authentication, authorization, enrollment, unenrollment, recovery, invalidation, and setup.

#Flow Executor

The engine that runs the flow. It works iteratively: invoke the next stage, present the challenge (question) to the user, wait for the answer, validate it, then move on to the next stage — until the flow completes or stops.

#Stage Binding

How stages are assembled in a flow. The binding order is the execution order. You can add, remove, reorder, and enable or disable bindings at any time — and the changes take effect immediately.

#Policy Binding

Both stages and flows can be wrapped in a policy. If the policy returns "allow", the stage runs; if "deny", the stage is skipped. The most tangible example: MFA is only required when login comes from a foreign IP — the policy evaluates, and the authenticator validation stage runs or is skipped. We'll dissect policies in episode 6.

#Compatibility Mode

A special mode for flows that mimic the behavior of older Authentik versions. Almost all cases use modern mode; leave it at the default.

#Stage Types

Some of the most frequently used stages:

• Identification stage — asks for an identifier (username or email). This is the first gate of almost every login flow.
• Password stage — validates the password against the user source.
• Authenticator validation stage — validates MFA devices (TOTP, WebAuthn) during login.
• Authenticator setup stage — enrolls new MFA devices (used during enrollment or setup).
• User login stage — marks the user as logged in and completes the session.
• User write stage — saves data from a prompt to the user (used during enrollment).
• Consent stage — asks the user to consent to the application's claims (often appears in OIDC flows).
• Email stage — sends and verifies a code via email.
• Prompt stage — shows a custom form; you're free to define any fields.
• Deny stage — stops the flow with a denial.
• Dummy stage — always succeeds; used for testing.

identification
  -> password
  -> authenticator_validate   (only if a policy requires MFA)
  -> user_login
  -> continue to application redirect

#Built-in Flows

After installation, Authentik creates default flows that work out of the box:

• default-authentication-flow — the standard login flow.
• default-enrollment-flow — the new user registration flow.
• default-recovery-flow — the password reset flow.
• default-invalidation-flow — the logout flow.

Open the admin interface → the Flows menu, select default-authentication-flow, and you'll see the list of stage bindings and their order. This is the best way to learn: dissect a working flow before assembling your own.

#Creating a Custom Flow

Steps to create a new flow in the admin interface:

1. Open Flows → Create Flow, give it a name (for example kiosk-authentication-flow) and choose the right designation.
2. Once saved, open the flow and choose Stage Binding → Create Stage Binding.
3. Select an existing stage or create a new one, then arrange its order.
4. Add a Policy Binding if needed — for example, only run the flow at certain times.
5. Test the flow via the Flow Inspector (explained below).

A flow can also point to another flow as the next destination — for example, after the authentication flow completes, the user is directed to the authorization flow of a specific application.

flow: kiosk-authentication-flow
designation: authentication
 
stage bindings (execution order):
  1. identification       prompt username
  2. password             validate password
  3. user_login           mark user as logged in
  4. redirect             to the application destination page
 
policy binding:
  - mfa-untuk-ip-asing    true -> enable authenticator_validate

#Flow Inspector and Debugging

When a flow completes, Authentik provides the Flow Inspector — you can open the execution details and see every stage that ran, the result of each policy, and the data that was passed. This is the most valuable debugging tool in all of Authentik.

• How to use it: run a flow (for example login), then look at the event in the admin interface → Events. You'll see the complete execution trail.
• Execution logs: Events and server logs (docker compose logs -f server) record stage failures.
• Common problems: a stage fails because a policy binding isn't satisfied, an email stage has no SMTP configured, or authenticator validation asks for a device when none is enrolled.

#Login Flow Diagram

Here's a summary of how flows & stages work in a single simple login:

User / Browser                Authentik (flow executor)
   |  1. open app (not logged in) |
   |------------------------------>|
   |                              |  find flow designation = authentication
   |  2. challenge: username  <---|--- stage identification
   |  3. send username  -------->|
   |  4. challenge: password  <---|--- stage password
   |  5. send password  -------->|
   |                              |  policy: MFA required? (false -> skipped)
   |  6. user_login  -------------|  stage user_login
   |  7. redirect to app <--------|
   |------------------------------>|

#Closing

In this episode 4, you understood the core of Authentik: flows with designations as their purpose, stage bindings as the assembly, policy bindings as the controller, and the flow executor as the engine running everything. You got to know the stage types — identification, password, authenticator validation & setup, user login, user write, consent, email, prompt, deny, and dummy — analyzed built-in flows like default-authentication-flow, learned to create custom flows, and met the Flow Inspector for debugging.

Key takeaways:

• Everything is a flow — login, registration, reset, logout, MFA setup.
• Stages are blocks; flows are sequences; policies are switches.
• Flow Inspector is the first debugging tool when a flow misbehaves.
• Always duplicate a built-in flow before editing it.

In episode 5, we'll manage users, groups, and attributes: creating users and groups, understanding user properties and service accounts, custom attributes used by policies, user sources from LDAP to social login, and bulk import via the API. See you in episode 5!