Restore User Context

Retrieves and reinstates a previously saved user context, enabling the journey to continue with the user’s established session and data

Description

The Restore User Context step enables a journey to securely reinstate a previously established user context, achieving an authenticated state without requiring the user to re-authenticate. This allows the journey to perform actions such as MFA, authenticator registration, or device management.

For journeys that occur in separate sessions from the initial login (such as post-login actions or profile updates), securely managing the user’s context across these journeys is essential. Typically, this involves collecting and saving the user’s context during the initial login journey using one of the following steps:

• The Cross-Session Message (CSM) step, that stores a customizable JSON object with user-specific data that can be accessed across journeys.
• The Save Data in SDK , that stores individual key-value pairs client-side, accessible in future sessions via @policy.sdkSavedData() .

Once user information is collected and securely handled during an initial login or similar journey, the Restore User Context step can retrieve and reinstate that user’s saved context in subsequent journeys. This avoids redundant authentication steps, creating a seamless experience for the user.

Configuration

Example

Consider a banking app where a user logs in and performs routine actions. During the login journey, the platform collects and securely saves essential user context data—such as the access_token, session_id, and user_id—so this information can be reused without requiring the user to log in again. To ensure the user’s context is available in subsequent journeys, the login journey stores this data using either Cross-Session Message (CSM), which stores data server-side, or Save Data in SDK, which stores it client-side.

Later, when the user initiates a sensitive action like updating their home address, the journey includes the Restore User Context step to retrieve the stored data and populate @policy.userContext(). This step enables the journey to recognize the user as authenticated and proceed securely with the update, without requiring an additional login.

Here’s an example of the @policy.userContext() object after it’s restored. The data within this object will vary based on what was initially set to be collected:

{
  "access_token": "abc123xyz",
  "id_token": "id123token",
  "session_id": "session456",
  "refresh_token": "refresh789",
  "user_id": "user001",
  "external_user_id": "external_user001"
}