Authenticate a member according to the organization's configured authentication policy
This step authenticates a member of a B2B organization. The journey defines the orchestration; the configuration of the member's organization determines how the member authenticates at runtime. A single journey serves organizations with different authentication configurations, without modeling organization-specific logic in the journey.
Use this step together with Register Member Authenticators to build member invite and login flows. It combines with any other journey step, including Collect Information.
This step presents the authentication 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:
- Resolves the organization from the value given in Organization (Email or Domain), so the applicable configuration is known before the authentication experience is presented.
- Authenticates the member according to how the organization is configured:
- Where the organization inherits the application's configuration, presents the methods the application marks as shown for sign-in. Where the application requires MFA, the member proceeds to a second factor using the methods marked as shown for MFA. See Configure B2B authentication settings.
- Where the organization uses federated access, redirects the member to its SAML or OIDC Identity Provider (IdP). See Configure federated access.
- Determines whether the member is associated with more than one organization, and presents organization selection where they are.
- Sets the selected organization on the journey context.
Identifier source decides how the step gets the member's identifier. The two options differ only in where and when the value is collected—once the member is identified, authentication behaves the same way.
The user is not authenticated, perform this step according to the identifier in the following parameter. You supply the value in Identifier, as an AuthScript expression—typically the output of a preceding Collect Information step. The step doesn't present identifier collection. Use this option to control the collection experience and add your own journey logic around it.
The user is not authenticated, collect the identifier from the user at runtime. The member first selects an authentication method. If the selected method requires an identified member, the step then collects the type set in Identifier type. Methods that identify the member themselves—discoverable or cross-device passkeys—proceed straight to authentication.
The identifier is collected at most once during the authentication flow. If another method subsequently requires the member to be identified, the existing identifier is reused.
Supported identifier types are email, phone, and username. Identifier type applies to every method except passkey, which never uses an identifier.
For federated organizations, no identifier is collected in either mode. The member is identified from the authentication response returned by the Identity Provider. For OIDC, the member's email is resolved from the claim configured in the organization's Email Claim setting.
Organization selection applies when the authenticated member is associated with more than one organization under the same application. Members are presented with their organizations only after successful authentication, so organization membership is never exposed to an unauthenticated caller.
If the member selects an organization other than the one used for the initial authentication, re-authentication is performed according to the selected organization's configuration: a redirect to its Identity Provider if it uses federated access, or the application's methods if it doesn't. Re-authentication isn't required only when neither the original nor the selected organization uses federated access.
This step handles organization resolution and selection natively. The Set Organization and Select Organization steps are removed from the step catalog for new journeys.
For federated organizations, just-in-time member creation can be enabled in the organization's configuration. When it's enabled, a member who authenticates successfully at the Identity Provider but doesn't yet exist in Mosaic is created and considered authenticated. When it's disabled, that member isn't created and isn't considered authenticated, even though authentication at the Identity Provider succeeded.
Organizations that inherit the application's configuration don't create members automatically. If your application supports sign-up in that case, build the branching logic into the journey—typically with a Collect Information step before Authenticate User, whose output determines whether and how the member should be created.
The authentication experience doesn't reveal whether a member exists, or which authentication methods they have registered. The same member-facing failure is presented when:
- The supplied identifier doesn't match a member.
- The member hasn't registered the selected authentication method.
- The member record doesn't contain a required attribute.
On success, the step follows the success branch and the selected organization is set on the journey context. The organization data is then available to subsequent steps via @organizations.current() expressions, for example @organizations.current().organization_id or @organizations.current().name.
On failure, the authentication error is returned through the step's error output variable, the step follows the failure branch, and the session ends. Failures use the platform conventions for authentication and external Identity Provider errors—see Journey errors.
| Field | Description |
|---|---|
| Identifier source | Where the member's identifier comes from: an expression you author, or a value collected from the member at runtime. |
| 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. 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. Required. |
| 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 login journey that serves every organization on your application. A Collect Information step presents a form that collects the member's email. In our example, the step ID is loginForm and the schema contains email.
In the Authenticate User step, Identifier source is set to take the identifier from a parameter, Identifier type to email, and Identifier to the form output, using loginForm.email. Organization (Email or Domain) takes the same value, since the organization is resolved from the email's domain. Because the identifier is supplied, the step doesn't ask for it again.
At runtime, members of an organization that inherits the application's configuration are presented with the application's sign-in methods, while members of a federated organization are redirected to their own Identity Provider. The same journey serves both.