The login journey encompasses a series of steps that guide customers through identifying their account, performing required authentication steps, and completing any missing account requirements needed to access an application.

Each of these steps contributes to the overall flow of validating the customer and ensuring secure access.

1. App launch: The login process begins when the brand's application starts a login flow with Strivacity.
2. Identify step: The first step involves identifying the customer through an identifier, such as username, email, phone, or external login credentials. This step can also determine organization membership of the account.
3. Authenticate step: Once the identifier is provided, the system authenticates the customer based on the Adaptive Access policy.
4. Progressive profiling: This step captures additional customer information, (e.g. required attributes, mandatory consents) that are required before application access is allowed.
5. MFA enrollment: This step requires a user to register any outstanding MFA enrollment requirements, per the Adaptive Access policy.
6. OIDC token or SAML2 response generation: After successful authentication, the system generates an ID token, which can be an OIDC token or a SAML2 assertion, depending on the protocol in use.
7. Redirect: Finally, the customer is redirected to the appropriate destination after a successful login.

Each step in the login workflow can be affected by specific conditions, such as account lockouts due to failed password attempts or the presence of MFA requirements. Lifecycle event hooks can also be implemented at various points to trigger additional actions before or after key steps, e.g. before password validation or after external login.

Extensibility points

Strivacity's customer journeys have various points where custom Journey Builder workflows and Lifecycle Event Hooks can be inserted to extend the natively configured workflows. These extensibility points are triggered by various events that happen during the customer journey.

There are two types of hooks: synchronous, which pauses Strivacity’s workflow until the script completes execution, and asynchronous, which runs the script without interrupting the workflow.

In the login journey, the following extensibility points are available:

At failed identification: This event triggers when a customer fails identification in the application's identity store, providing specific reasons for the failure, such as account disabled, unactivated account, group restriction, or account doesn't exist. This hook allows you to re-identify the customer by adjusting lookup parameters, create a new account and continue, display a custom screen, redirect to an external page, or initiate a journey. Synchronous hook.

After customer identification: This event is triggered once the customer has provided their identifier (email address, username, or phone) and before they are asked for any factor of authentication. This hook can be used to step up or step down the login flow based on an external event, risk data from an external system, or other customer account attribute information. Synchronous hook.

After external login: This hook can trigger an event or retrieve data from an external system after a customer registers or logs in with a social login provider, potentially affecting the flow. Synchronous hook.

Before password validation: This event is triggered when a customer's account doesn't have a password authenticator yet. This hook can retrieve the password from an external identity store if the customer's account was migrated, and reset the password in the Strivacity identity store with the migrated password. The hook also allows for the validation of the password through an external system without having to store it in the Strivacity identity store. Synchronous hook.

At failed authentication: This event triggers when customer authentication or registration fails. This hook provides the reason for the failure, allowing you to customize the error returned, display an error page with a custom message, or redirect the customer based on the failure context. Synchronous hook.

Before progressive profiling: This event activates after completing the first registration step or during login, enabling additional steps in workflows for progressive profiling. Some example use cases are asking for consents only in specific geographical areas, introducing mandatory fields or consents as optional for the first time, or validating a customer ID by reaching out to a third-party system. Synchronous hook.

After account update: This event is triggered after an account has been updated. This hook can be used to sync accounts to an external identity store. Asynchronous hook.

Before authenticator enrollment: This hook allows you to customize the MFA enrollment workflow based on customer behavior or information collected from external systems such as CMRs, marketing hubs, or data analytics platforms. Additionally, it can override the MFA enrollment plan defined in the adaptive access policy for the application. You can control the appearance of enabled authenticators, such as email, phone, platform biometrics, etc. However, the methods associated with those authenticators (e.g., magic link, passcode) cannot be configured through the event hook. This hook also lets you enforce a specific email or phone number authenticator, even when restrictions apply. You can require customers to enroll in one of the enabled authenticators if every method is set to optional in the basic MFA flow, or prompt them to change their password. Synchronous hook.

Before password persist: This event is triggered immediately prior to the password persistence to external or internal databases, enabling custom validation and synchronization steps before persisting the new password. Synchronous hook.

After MFA change: This hook can trigger an external event or fetch data from an external system once the customer has completed the verification of a new/additional MFA factor during enrollment or removed a factor. Asynchronous hook.

Before ID token generation: This event activates before generating the ID token, enabling the addition of custom claims or data from an external system to the ID or access token. Synchronous hook.

Before SAML2 assertion generation: This event activates before generating a SAML2 assertion, allowing custom attributes to be added to a SAML2 response by pulling data from an external system. Synchronous hook.

After self-service login: This event is triggered upon successful login, relaying confirmation of login success to the hook. Asynchronous hook.