Has Valid SSO Session
Checks whether the current journey is running in the context of an SSO session
Description
This step is used to verify whether the current journey is executed in the context of a valid SSO session, meaning the user's session is still active and has not expired after a successful authentication.
Additionally, it allows access to information collected by the Enrich SSO Session step during previous runs of this journey, accessible via the output parameter. It also automatically loads the @policy.userContext()
created during previous runs of the journey in this session. This output provides two levels of session_id
, each with a different scope:
-
SSO session ID (
ssoSession.session_id
) : identifies the session managed by the SSO service. It spans across multiple invocations of the same journey as long as the SSO session is active. This ID enables seamless state management, allowing the journey to reload and renew the user’s state when they return, without requiring re-authentication. For example, it ensures continuity across interactions within the same session lifecycle, even if the journey is invoked repeatedly. -
User session ID (
@policy.userContext().session_id
) : relates to the backend authentication state of the user. It is tied specifically to the user's authentication tokens and is used for operations such as logging out or accessing secure resources. Unlike the broader SSO session ID, the user session ID focuses on the individual authentication event. For a detailed explanation of backend authentication sessions, refer to How Backend Sessions Work .
This step is useful in the following cases:
- Perform a silent login if the user is in a valid SSO session.
- Inspect previous authentications made in this session and decide if a step-up authentication is needed.
- Inspect custom data stored during previous authentications and act on it.
Configuration
Field | Description |
---|---|
Output Variable | If the session is valid, this variable will contain the session information as demonstrated below. |
Example
Consider a journey that performs Device Validation, which generates an output variable called key_id
associated with the device validation. Keeping the key_id
as part of the session enrichment is useful to run inspections and ensure that all SSO activity occurs in the context of the same device during subsequent runs. The Has Valid SSO Session step collects data from previous runs, and allows inspection of this information via its output variable, which provides the session history in the following JSON format:
{
"session_id": "cd32709e-930...", // SSO Session ID
"sso_group_id": {
"id": "zWEqcqgZCuqki6khmOVYO"
},
"session_ttl_seconds": 8640000,
"last_access": 1731082051883,
"expires": 1739722051883,
"state": "established",
"user_tokens": {
"access_token": "eyJhbG...)",
"id_token": "eyJhb...",
"refresh_token": "XiBOKqI...",
"session_id": "Q5Oy...", // User Session ID
"user_id": "abc123g0pum0nbnqinfjp",
"external_user_id": "user@company.com"
},
"enrichment_data": {
"session": { // Only appears if some SSO session-specific values have been set
"someKey1": "value",
"someKey2": "value",
...
},
"token": { // Only appears if some SSO token-specific values have been set
"someKeyA": "value",
"someKeyB": "value",
...
}
}
}