Register required and optional authenticators for a member according to the organization's configured authentication policy
This step registers the authentication methods a member needs, based on the registration settings defined for the application. It evaluates what the member has already registered and asks only for what's missing, so it can be placed in any flow without checking the member's state beforehand.
Use this step after Authenticate User, typically in a member invite flow or a login flow that brings members up to date with the application's registration requirements.
This step presents the registration screens itself, so the journey has to run on pages hosted by Mosaic. The client must be set to run journeys, and its login screens must be the Mosaic-hosted ones rather than your own.
The step isn't available where the client serves your own login pages, or in SDK-driven journeys. For the client settings this depends on, see X.
When triggered, the step:
- Receives the organization and the member identifier as input.
- Loads the registration settings that apply—which methods the application marks as required and which as optional. See Configure B2B authentication settings.
- Evaluates which of those methods the member has already registered, and skips them.
- Registers the outstanding required methods, then offers the outstanding optional ones.
- Associates the member with the organization.
Authenticator registration requires an existing member. If the journey is responsible for creating the member, member creation must happen before this step.
Required methods are presented one at a time, and the member can't continue past one until it's registered. Optional methods follow, and each can be skipped. If the member already satisfies the registration settings, the step completes without presenting anything.
Members of federated organizations aren't asked to register anything—credentials are managed by the organization's Identity Provider—and the step completes immediately.
Organization selection doesn't occur during or after registration. It applies only after authentication, where an existing member may be associated with more than one organization. See Authenticate User.
The step registers the completed authenticators to the member's record. The methods the member registered are part of the step's outcome, so a later step in the journey can act on them.
The step succeeds once every required method is registered, and fails where a required method isn't completed within the permitted retries. Failure of an optional method doesn't fail the step—the step continues and completes as a success. Failures are reported using the platform conventions for registration errors—see Journey errors.
| Field | Description |
|---|---|
| Identifier source | Where the member's identifier comes from. Select The user is already authenticated to reuse the member identified earlier in the journey, or The user is not authenticated, perform this step according to the identifier in the following parameter to supply it yourself. |
| Identifier type | The member attribute the step looks the member up by: email, phone, or username. It applies to every method except passkey, which never uses an identifier. |
| Identifier | AuthScript expression that resolves to the member's identifier, for example clientData.userEmail. Shown when the identifier is supplied as a parameter. |
| Organization (Email or Domain) | The organization's domain, or any email address at that domain—Mosaic infers the domain. Determines the applicable organization configuration. |
| Error output variable | Name of the variable that stores any errors returned by the step. Defaults to error. |
| Failure behavior | Determines the behavior in case of failure, which either aborts the journey or proceeds to a failure branch of the control flow (default). |
This step can be configured to record step input and output data, or a custom payload, which is then surfaced in journey events in Journey Analytics for diagnostic purposes. For details, see Additional data reporting.
Consider a member invite flow. An organization admin adds a member, who receives an invitation and follows the link into the journey. The journey authenticates them with Authenticate User, then invokes Register Member Authenticators with Identifier source set to The user is already authenticated, so the member identified by the previous step is reused.
Suppose the application requires password and passkey for registration, and marks TOTP as optional. A member who already has a password is asked only for the passkey, and is then offered TOTP with the option to skip it. Once the passkey is registered, the step succeeds—whether or not the member registered TOTP.