This repository has been archived on 2024-05-31. You can view files and clone it, but cannot push or open issues or pull requests.
authentik/website/docs/flow/flows.md
Jens L 7be680cbe5
Migrate to Docusaurus (#329)
* docs: initial migration to docusaurus

* website: add custom font, update blurbs and icons

* website: update splash

* root: update links to docs

* flows: use .pbflow extension so docusaurus doesn't mangle the files

* e2e: workaround prospector

* Squashed commit of the following:

commit 1248585dca
Author: Jens Langhammer <jens.langhammer@beryju.org>
Date:   Sun Nov 15 20:46:53 2020 +0100

    e2e: attempt to fix prospector error again

commit 1319c480c4
Author: Jens Langhammer <jens.langhammer@beryju.org>
Date:   Sun Nov 15 20:41:35 2020 +0100

    ci: install previous python version for upgrade testing

* web: update accent colours and format

* website: format markdown files

* website: fix colours for text

* website: switch to temporary accent colour to improve readability

* flows: fix path for TestTransferDocs

* flows: fix formatting of tests
2020-11-15 22:42:02 +01:00

47 lines
2.6 KiB
Markdown

---
title: Flows
---
Flows are a method of describing a sequence of stages. A stage represents a single verification or logic step. They are used to authenticate users, enroll them, and more.
Upon flow execution, a plan containing all stages is generated. This means that all attached policies are evaluated upon execution. This behaviour can be altered by enabling the **Re-evaluate Policies** option on the binding.
To determine which flow is linked, passbook searches all flows with the required designation and chooses the first instance the current user has access to.
## Permissions
Flows can have policies assigned to them. These policies determine if the current user is allowed to see and use this flow.
## Designation
Flows are designated for a single purpose. This designation changes when a flow is used. The following designations are available:
### Authentication
This is designates a flow to be used for authentication.
The authentication flow should always contain a [**User Login**](stages/user_login.md) stage, which attaches the staged user to the current session.
### Invalidation
This designates a flow to be used to invalidate a session.
This stage should always contain a [**User Logout**](stages/user_logout.md) stage, which resets the current session.
### Enrollment
This designates a flow for enrollment. This flow can contain any amount of verification stages, such as [**email**](stages/email/index.md) or [**captcha**](stages/captcha/index.md). At the end, to create the user, you can use the [**user_write**](stages/user_write.md) stage, which either updates the currently staged user, or if none exists, creates a new one.
### Unenrollment
This designates a flow for unenrollment. This flow can contain any amount of verification stages, such as [**email**](stages/email/index.md) or [**captcha**](stages/captcha/index.md). As a final stage, to delete the account, use the [**user_delete**](stages/user_delete.md) stage.
### Recovery
This designates a flow for recovery. This flow normally contains an [**identification**](stages/identification/index.md) stage to find the user. It can also contain any amount of verification stages, such as [**email**](stages/email/index.md) or [**captcha**](stages/captcha/index.md).
Afterwards, use the [**prompt**](stages/prompt/index.md) stage to ask the user for a new password and the [**user_write**](stages/user_write.md) stage to update the password.
### Setup
This designates a flow for general setup. This designation doesn't have any constraints in what you can do. For example, by default this designation is used to configure Factors, like change a password and setup TOTP.