User self-registration flows configuration

To configure user self-registration flows, go to:
Loginapp >> Self-Registration

Example flow

The example used in this article is based on this flow configuration:


By default, self-registered accounts are locked when they are initially created. In the Initial Lock Reason parameter, the lock reason of the initial lock can be configured.

The Password Repository parameter is used to define how passwords of the newly created user are stored.

Configuration of the User Data Registration Step

A User Data Registration Step contains one or more user data items.

A user data registration step may also configure a validator to validate rules that are applicable to more than one user data item and force the user to solve a CAPTCHA before continuing the flow.


Context data items may be marked as required and validators can be added to ensure that only properly formatted data is accepted by the system. 


As an alternative to the Regex String Validator, an Email Address Validator is also provided as a way to conveniently validate email addresses.

  • It is recommended to carefully validate the length and content of data sent by (potentially adversarial) users:
  • Use the existing validators, e.g. for email addresses and phone numbers.
  • Limit the allowed length of the received data by using a regular expression.
  • Whitelist allowed characters in strings using a regular expression.

Username Generation Step

The Username Generation Step is used to generate a user ID. It is used if the information entered by the user cannot be used as a unique username. If the user, for example, registers the email address and you do not want to use it as unique identifier of the account, a Username Generation Step is required. Note that, in this example, you may still use the email address to log in afterwards.

The username generator supports two types of generators. One producing UUIDs and one generating random IDs based on a configurable pattern.


Notes on identity verification steps

There are several identity verification steps based on sending emails or SMS messages. Identity verification steps can be used to achieve different goals:

Goal of identity verification

Configuration requirements

Ensure that the user entered the email address or phone number correctly (no typos).

The verification OTP can be short to increase usability since brute-forcing is pointless. Stealth mode is not needed.

Alternatively, an email link can be sent to the user.

Ensure that the user is in control of the email address or phone number.

The verification OTP should be long enough to prevent brute-forcing (by repeatedly restarting the self-registration). Stealth mode is not needed.

Alternatively, an email link can be sent to the user.

Prevent users from finding out if someone else's email address or phone number is already registered.

This is the only use-case that requires stealth mode (see below). In addition, a long OTP should be used to prevent probabilistic enumeration attacks.

Alternatively, an email link can be sent to the user.

Email Verification Step

The Email Verification Step sends an email with an OTP to the email address registered in a previous step of the flow. It requires an email service, an OTP generator, and a message template:


Note that the Max Failed Attempts property only limits the number of attempts to enter the correct OTP. It cannot prevent repeated registration attempts with the same email address.

Phone Number Verification Step

The Phone Number Verification Step sends an SMS to the mobile phone number registered in a previous step. It requires an SMS Gateway, an OTP generator, and a message template.


Note that the Max Failed Attempts property only limits the attempts to enter the correct OTP. It cannot prevent repeated registration attempts with the same phone number.

Configuration of Password Registration

Another User Data Registration Step is configured to allow the user to choose a password.


Note that the Loginapp UI automatically provides a user interface in which the user has to enter the password twice.

User Role Assignment Step

The User Role Assignment Step can be used to assign static roles to the user.


A role assigned during self-registration is persisted with the user and may be used for authorization decisions in other flows.

Airlock 2FA Activation Step

The Airlock 2FA Activation Step allows the user to enroll the Airlock 2FA App directly during self-registration.

To configure the Airlock 2FA Activation Step, the Airlock 2FA Settings and an Enrollment Timeout must be set.


Note that enrolling the Airlock 2FA App during the self-registration and using it as 2nd factor does not necessarily lead to strong authentication.

While it greatly improves the confidence that a returning user is the same as the one that self-registered, it does not prove that the user really is who he or she claims to be.

In order to ensure the authenticity of the self-registered user (making sure the user is who he or she claims to be) and additional verification is strictly required (e.g. ID proofing, activation letter, or similar).

It is not possible to combine an Airlock 2FA Activation Step with an Airlock 2FA Activation Letter Order Step in the same self-registration flow.

Active Authentication Method Step

Use the Active Authentication Method step with AIRLOCK_2FA for the Auth Method parameter to directly configure the user account with Airlock 2FA as the authentication method.


User Unlock Step

By default, all users are locked when they start a self-registration flow. A User Unlock Step must be configured to change the newly created account's state to unlocked.

The User Unlock Step must be configured before the last User Persisting Step to ensure that the user account is stored as unlocked.

User Persisting Step

The User Persisting Step stores the data determined in the previous steps in the database and with it creates the IAM user account. It is usually, but not necessarily the last step. Typically confirmation (using the Acknowledge Message Step) is shown after storing the account.


Note that some steps may require a stored user account and must be placed after the User Persisting Steps.

Example: Send Email Link Step

Using the email address as a login alias

An alias is a context data item that is configured to be used to log in with (instead of the username).

The use of the user's email address as an alias is a recommended best practice for the configuration of user self-registration. Done correctly several goals can be achieved without any impact on the user experience:

  1. Using the email address as an alias makes it very simple for the user to remember the login name.
  2. Segregating email and username allows the user to modify the email address during the lifetime of the account.
  3. If the email alias is the target of the first channel verification, the stealth mode feature can effectively protect it against enumeration attacks.

Configuring a context data item as an alias already ensures that the context data item is unique in the database. Additionally configuring a uniqueness constraint on the same User Profile Item will therefore lead to conflicts and should be avoided.

Care should be taken when configuring self-registration flows for accounts with alias usernames without verification steps. Such setups are subject to race conditions and it may be possible for an attacker to generate multiple user accounts with the same alias. While such accounts are unusable and will not affect the normal operation of Airlock IAM, it is not desirable for an attacker to be able to create them.

To avoid this problem, it is possible to configure a unique index on the database to force all attributes in the username alias to be unique.

Multiple self-registration flows

It is possible to configure multiple self-registration flows. How to select one of the flows is explained in Loginapp REST API Reference (and in User Self-Registration UI plugin for the Loginapp UI).


Note that allowing several self-registration flows may have security impacts:

  • As the REST client may choose the flow to register a user account, an attacker may choose the weakest flow. E.g., if one of the flows allows registration without channel verification, the adversary may choose that flow in order to register users easily.
  • If Stealth Mode is used, a flow protects against enumeration of a specific channel verification target. Ensure that other flows cannot be used to enumerate that channel verification target. E.g., enumeration is possible if a channel verification target 'email' is used in one flow and 'email' can be set without channel verification in a different flow.

Limitations with LDAP directories and MSAD

There are limitations when using the self-registration features with LDAPs and MSAD.

Data Persister


IAM database

No known limitations.

LDAP directory

The only data type supported is a string. Data type boolean or date cannot be used.


Microsoft AD may work with the LDAP Connector but this is not a supported use case.

Further information and links