Custom Authentication
Authenticates the user based on a token generated by an external identity provider (e.g., legacy system)
Description
This step can be used to authenticate users based on an external token. For example, this can be used when migrating users from a legacy system to Mosaic, or authenticating users using a custom method via an external identity provider.
This step validates external tokens using a token validation service that's configured as an external connection. This service evaluates the relevant claims associated with the token. This includes checking that the token corresponds to the username provided by the step. Once completed, the service returns a validation result, for example, valid or invalid.
If token validation succeeds, journey execution resumes with the next step. If token validation fails (e.g., if the token is invalid or there was a failure invoking the token validation service), the journey terminates.
Configuration
| Field | Description |
|---|---|
| Username | User identifier, specified as an expression. This must match the user of the external token |
| Token to Validate | External token to validate in this step, specified as an expression. |
| Token Validator | External connection that represents the token validation service. |
| Error Output Variable | Name of the variable that stores any errors returned by the token validation service |
| Failure Behavior | Determines the behavior in case of failure, which either aborts the journey (default) or proceeds to a failure branch of the control flow. |
Examples
Here's an example of how this step can be used.
Example 1: Migrating users
Consider a journey that's used to migrate users from a legacy system to Mosaic. For example, after the user logs in using the legacy provider, a journey is initiated to authenticate the user in Mosaic based on the external login and then register passkey biometrics for future authentications (using the Register Passkeys step).
The username and external token can be provided by the client that invokes the journey as part of the request. In our example, the client passes them in the SDK call as additional parameters named username and externalToken:
// Start a journey with the ID 'my-journey-id'
try {
const idoResponse = await window.tsPlatform.ido.startJourney(
'my-journey-id',
{
additionalParams:
{
username: 'username', // User identifier
externalToken: 'external-token' // External token to validate auth
}
}
);
// Handle Journey response
} catch(error) {
switch(sdkError.errorCode) ...
}The journey step can access the username using @policy.request().params.username and the external token using @policy.request().params.externalToken:
