keycloak-scim/server_admin/topics/authentication/flows.adoc

[[_authentication-flows]]

=== Authentication Flows

An _authentication flow_ is a container of authentications, screens, and actions, during log in, registration, and other {project_name} workflows.
To view all the flows, actions, and checks, each flow requires:

.Procedure
. Click *Authentication* in the menu.
. Click the *Flows* tab.

==== Built-in flows

{project_name} has several built-in flows. You cannot modify these flows, but you can alter the flow's requirements to suit your needs.

In the drop-down list, select *browser* to display the Browser Flow screen.

.Browser Flow
image:{project_images}/browser-flow.png[Browser Flow]

Hover over the question-mark tooltip of the drop-down list to view a description of the flow. Two sections exist.

===== Auth type
The name of the authentication or the action to execute. If an authentication is indented, it is in a sub-flow. It may or may not be executed, depending on the behavior of its parent. 

. Cookie
+
The first time a user logs in successfully, {project_name} sets a session cookie.  If the cookie is already set, this authentication type is successful. Since the cookie provider returned success and each execution at this level of the flow is _alternative_, {project_name} does not perform any other execution. This results in a successful login.

. Kerberos
+
This authenticator is disabled by default and is skipped during the Browser Flow.

. Identity Provider Redirector
+
This action is configured through the *Actions* > *Config* link. It redirects to another IdP for <<_identity_broker, identity brokering>>.

. Forms
+
Since this sub-flow is marked as _alternative_, it will not be executed if the *Cookie* authentication type passed. This sub-flow contains an additional authentication type that needs to be executed. {project_name} loads the executions for this sub-flow and processes them.

The first execution is the *Username Password Form*, an authentication type that renders the username and password page. It is marked as _required_, so the user must enter a valid username and password.

The second execution is the *Browser - Conditional OTP* sub-flow. This sub-flow is _conditional_ and executes depending on the result of the *Condition - User Configured* execution. If the result is true, {project_name} loads the executions for this sub-flow and processes them.

The next execution is the *Condition - User Configured* authentication. This authentication checks if {project_name} has configured other executions in the flow for the user. The *Browser - Conditional OTP* sub-flow executes only when the user has a configured OTP credential.

The final execution is the *OTP Form*. {project_name} marks this execution as _required_ but it runs only when the user has an OTP credential set up because of the setup in the _conditional_ sub-flow. If not, the user does not see an OTP form.

===== Requirement
A set of radio buttons that control the execution of an action executes.

[[_execution-requirements]]
====== Required

All _Required_ elements in the flow must be successfully sequentially executed. The flow terminates if a required element fails.

====== Alternative

Only a single element must successfully execute for the flow to evaluate as successful. Because the _Required_ flow elements are sufficient to mark a flow as successful, any _Alternative_ flow element within a flow containing _Required_ flow elements will not execute.

====== Disabled

The element does not count to mark a flow as successful.

====== Conditional

This requirement type is only set on sub-flows. 

* A _Conditional_ sub-flow contains executions. These executions must evaluate to logical statements. 
* If all executions evaluate as _true_, the _Conditional_ sub-flow acts as _Required_. 
* If all executions evaluate as _false_, the _Conditional_ sub-flow acts as _Disabled_.
* If you do not set an execution, the _Conditional_ sub-flow acts as _Disabled_. 
* If a flow contains executions and the flow is not set to _Conditional_, {project_name} does not evaluate the executions, and the executions are considered functionally _Disabled_.

==== Creating flows

Important functionality and security considerations apply when you design a flow.

To create a flow, perform the following:

.Procedure
. Click *Authentication* in the menu.
. Click *New*.

[NOTE]
====
You can copy and then modify an existing flow. Select a flow, click *Copy*, and enter a name for the new flow.
====

When creating a new flow, you must create a top-level flow first with the following options:

Alias::
  The name of the flow.
Description::
  The description you can set to the flow.
Top-Level Flow Type::
  The type of flow. The type *client* is used only for the authentication of clients (applications). For all other cases, choose *generic*.

.Create a top-level flow
image:{project_images}/Create-top-level-flow.png[Top Level Flow]

When {project_name} has created the flow, {project_name} displays the *Delete*, *Add execution*, and *Add flow* buttons.

.An empty new flow
image:{project_images}/New-flow.png[New Flow]

Three factors determine the behavior of flows and sub-flows.

* The structure of the flow and sub-flows.
* The executions within the flows
* The requirements set within the sub-flows and the executions.

Executions have a wide variety of actions, from sending a reset email to validating an OTP. Add executions with the *Add execution* button. Hover over the question mark next to *Provider*, to see a description of the execution.

.Adding an authentication execution
image:{project_images}/Create-authentication-execution.png[Adding an Authentication Execution]

Two types of executions exist, _automatic executions_ and _interactive executions_. _Automatic executions_ are similar to the *Cookie* execution and will automatically
perform their action in the flow. _Interactive executions_ halt the flow to get input. Executions executing successfully set their status to _success_.  For a flow to complete, it needs at least one execution with a status of _success_. 

You can add sub-flows to top-level flows with the *Add flow* button. The *Add flow* button displays the *Create Execution Flow* page. This page is similar to the *Create Top Level Form* page. The difference is that the *Flow Type* can be *generic* (default) or *form*. The *form* type constructs a sub-flow that generates a form for the user, similar to the built-in *Registration* flow.
Sub-flows success depends on how their executions evaluate, including their contained sub-flows. See the <<_execution-requirements, execution requirements section>> for an in-depth explanation of how sub-flows work.

[NOTE]
====
After adding an execution, check the requirement has the correct value.
====

All elements in a flow have a *Delete* option in the *Actions* menu. This action removes the element from the flow.
Executions have a *Config* menu option to configure the execution. It is also possible to add executions and sub-flows to sub-flows with the *Add execution* and *Add flow* menu options.

Since the order of execution is important, you can move executions and sub-flows up and down within their flows using the up and down buttons beside their names.

==== Creating a password-less browser login flow

To illustrate the creation of flows, this section describes creating an advanced browser login flow. The purpose of this flow is to allow a user a choice between logging in using a password-less manner with <<_webauthn, WebAuthn>>, or two-factor authentication with a password and OTP.

.Procedure
. Click *Authentication* in the menu.
. Click the *Flows* tab.
. Click *New*.
. Enter `Browser Password-less` as an alias.
. Click *Save*.
. Click *Add execution*.
. Select *Cookie* from the drop-down list. 
. Click *Save*.
. Click *Alternative* for the *Cookie* authentication type to set its requirement to alternative.
. Click *Add execution*. 
. Select *Kerberos* from the drop-down list. 
. Click *Add execution*.
. Select *Identity Provider Redirector* from the drop-down list. 
. Click *Save*.
. Click *Alternative* for the *Identity Provider Redirector* authentication type to set its requirement to alternative.
. Click *Add flow*.
. Enter *Forms* as an alias.
. Click *Save*.
. Click *Alternative* for the *Forms* authentication type to set its requirement to alternative.
+
.The common part with the browser flow
image:images/Passwordless-browser-login-common.png[]
+
. Click *Actions for the *Forms* execution.
. Select *Add execution*.
. Select *Username Form* from the drop-down list.
. Click *Save*.
. Click *Required* for the *Username Form* authentication type to set its requirement to required.

At this stage, the form requires a username but no password. We must enable password authentication to avoid security risks.

. Click *Actions* for the *Forms* sub-flow.
. Click *Add flow*.
. Enter `Authentication` as an alias.
. Click *Save*.
. Click *Required* for the *Authentication* authentication type to set its requirement to required.
. Click *Actions* for the *Authentication* sub-flow.
. Click *Add execution*.
. Select *Webauthn Passwordless Authenticator* from the drop-down list. 
. Click *Save*.
. Click *Alternative* for the *Webauthn Passwordless Authenticator* authentication type to set its requirement to alternative.
. Click *Actions* for the *Authentication* sub-flow.
. Click *Add flow*.
. Enter `Password with OTP` as an alias.
. Click *Save*.
. Click *Alternative* for the *Password with OTP* authentication type to set its requirement to alternative.
. Click *Actions* for the *Password with OTP* sub-flow.
. Click *Add execution*.
. Select *Password Form* from the drop-down list. 
. Click *Save*.
. Click *Required* for the *Password Form* authentication type to set its requirement to required.
. Click *Actions* for the *Password with OTP* sub-flow.
. Click *Add execution*.
. Select *OTP Form* from the drop-down list. 
. Click *Save*.
. Click *Required* for the *OTP Form* authentication type to set its requirement to required.

Finally, change the bindings.

. Click the *Bindings* tab.
. Click the *Browser Flow* drop-down list.
. Select *Browser Password-less* from the drop-down list. 
. Click *Save*.

.A password-less browser login
image:images/Passwordless-browser-login.png[]

After entering the username, the flow works as follows:

If users have WebAuthn passwordless credentials recorded, they can use these credentials to log in directly. This is the password-less login. The user can also select *Password with OTP* because the `WebAuthn Passwordless` execution and the `Password with OTP` flow are set to *Alternative*. If they are set to *Required*, the user has to enter WebAuthn, password, and OTP.

If the user selects the *Try another way* link with `WebAuthn passwordless` authentication, the user can choose between `Password` and `Security Key` (WebAuthn passwordless). When selecting the password, the user will need to continue and log in with the assigned OTP. If the user has no WebAuthn credentials, the user must enter the password and then the OTP. If the user has no OTP credential, they will be asked to record one.

[NOTE]
====
Since the WebAuthn Passwordless execution is set to *Alternative* rather than  *Required*, this flow will never ask the user to register a WebAuthn credential. For a user to have a Webauthn credential, an administrator must add a required action to the user. Do this by:

. Enabling the *Webauthn Register Passwordless* required action in the realm (see the <<_webauthn,WebAuthn>> documentation).
. Setting the required action using the *Credential Reset* part of a user's xref:ref-user-credentials_{context}[Credentials] management menu.

Creating an advanced flow such as this can have side effects. For example, if you enable the ability to reset the password for users, this would be accessible from the password form. In the default `Reset Credentials` flow, users must enter their username. Since the user has already entered a username earlier in the `Browser Password-less` flow, this action is unnecessary for {project_name} and sub-optimal for user experience. To correct this problem, you can:

* Copy the `Reset Credentials` flow. Set its name to `Reset Credentials for password-less`, for example.
* Select *Delete* in the *Actions* menu of the *Choose user* execution.
* In the *Bindings* menu, change the reset credential flow from *Reset Credentials* to *Reset Credentials for password-less*
====

ifeval::[{project_community}==true]
=== Script Authenticator

Ability to upload scripts through the Admin Console and REST endpoints is deprecated.

For more details see link:{developerguide_jsproviders_link}[{developerguide_jsproviders_name}].

endif::[]