Bindings in authentik
A binding connects one authentik object to another object that uses it. Bindings let authentik answer two common questions:
- Where should authentik evaluate this policy, user, or group?
- Where should authentik insert this stage into a flow?
A policy answers "should this request pass?" A policy binding decides where authentik asks that question.
For a step-by-step guide, see Work with bindings.
Binding types
The two most common binding types are policy bindings and flow-stage bindings.
- Policy bindings attach a policy, user, or group to a target that supports policy binding.
- Flow-stage bindings attach a stage to a flow and define where that stage runs.
Use a policy binding when you want to control whether a target is allowed, denied, or shown. Use a flow-stage binding when you want to place a stage into a flow and decide when it should run.
Where bindings are used
The policy binding system is shared by several authentik objects. You can bind policies, users, and groups to these targets:
| Target | What the binding controls |
|---|---|
| Flow | Whether the user can start or continue using the flow. |
| Flow-stage binding | Whether a specific stage applies to a user in that flow. |
| Application | Whether the user can view and access the application. |
| Application entitlement | Whether the user has access to an entitlement. |
| Source | Whether the source can be used for login or enrollment. |
| Device | Whether the device passes the configured access checks. |
| Device access group | Whether the device is part of the access group. |
| Notification rule | Whether the notification rule applies. |
| RAC endpoint | Whether the user can access the Remote Access endpoint. |
Stages themselves are not policy binding targets. A stage is attached to a flow through a flow-stage binding, so when you bind a policy to a stage in a flow, you are binding it to that flow-stage binding.
Because of this, the same stage can be reused in multiple flows, and each flow can apply different policies, users, groups, order, and evaluation settings to that stage.
Relationships
Policy bindings
A policy binding attaches one policy, user, or group to a target:
- A policy object can evaluate runtime data, request context, source data, user attributes, and other conditions.
- A user binding passes when the current user matches that user.
- A group binding passes when the current user is a member of that group.
User and group bindings are useful when you want a direct allow or deny rule without creating a separate policy object.
Policy bindings are commonly used with applications, sources, flows, flow-stage bindings, and application entitlements. For example, you can bind a group directly to an application so that only members of that group can view and launch the application.
Bindings are evaluated according to the target's Policy engine mode:
Any: the target passes when any binding passes.All: the target passes only when every binding passes.
authentik evaluates enabled bindings in ascending order. This order is most noticeable when you read logs or combine multiple policies that return messages.
Bindings also support these options:
- Negate, which flips the pass or fail result of the binding.
- Timeout, which limits how long authentik waits for policy execution.
- Failure result, which controls whether a policy error is treated as pass or fail.
Policy bindings attached directly to a flow are evaluated before the flow starts. In authentication and enrollment flows, that usually means that user- and group-based checks on the flow itself cannot pass until the user has already been identified elsewhere.
If a target has no applicable bindings, authentik treats the result as passing.
Flow-stage bindings
A flow-stage binding attaches a stage to a flow and defines the order in which that stage runs. Flow-stage bindings are also called stage bindings.
authentik uses flow-stage bindings while building the flow plan. The flow plan determines which stages a user sees and in what order.
This matters because stages are reusable objects. The same stage can appear in multiple flows, but each flow-stage binding can have its own settings. When you bind a policy to a stage in a specific flow, you bind it to that flow-stage binding, not to the reusable stage definition itself.
Stage-binding policy evaluation
Flow-stage bindings have two policy evaluation options:
- Evaluate when flow is planned: authentik evaluates policies while building the flow plan.
- Evaluate when stage is run: authentik evaluates policies immediately before presenting the stage.
At least one of these options must be enabled, and both can be enabled at the same time. For the full behavior and guidance on choosing the right setting, see Flow Planner.
What to remember
- Stages are attached to flows through flow-stage bindings.
- Policies, users, and groups can all be bound through the same policy binding system.
- The same stage can behave differently in different flows because each flow-stage binding has its own settings and bindings.
- A policy bound directly to a flow is evaluated earlier than a policy bound to a flow-stage binding.
Common examples
Restrict an application
By default, applications are accessible to all users. Bind a group or policy to an application when you want to limit access to specific users.
Run a stage only for some users
Bind a policy, user, or group to the flow-stage binding when a stage should appear only for certain users in that flow. For example, require an MFA stage only for specific users.
Scope access inside an application
Use application entitlements when you need to control access to parts of an application after the user already has access to the application. For example, control which users have access to administrator functions within an application.