Introduction to sessions
AM uses two types of tokens that represent an exchange of information, usually interactive, between AM and a user or identity:
-
Journey sessions, which AM creates to track progress through a journey. These sessions last for the duration of the journey.
-
Authenticated sessions, which AM creates after a user has authenticated successfully to manage the user’s or entity’s access to resources.
AM session-related services are stateless unless otherwise indicated. They don’t hold any session information local to the AM instances.
Instead, they store session information either in the CTS token store (server-side sessions) or on the client (client-side sessions).
Session location
Sessions have different characteristics depending on where AM stores the sessions.
Both journey sessions and authenticated sessions can be stored on the client or on the server.
Session location is configured at the realm level.
The following table illustrates where AM can store sessions:
| In the CTS token store | On the client | In AM’s memory | |
|---|---|---|---|
Journey sessions |
✔ |
✔ (Default in new installations) |
✔ (Default after upgrade) |
Authenticated sessions |
✔ (Default) |
✔ |
✖ |
|
You can configure different session locations within the same AM deployment to suit the requirements of each realm. You can also configure the journey session location independently of the authenticated session location. For example, you could configure the same realm for client-side journey sessions and server-side authenticated sessions if it suits your environment. |
Choosing where to store sessions is an important decision you must make by realm. Review the information in the following tables before configuring sessions.
Where to store journey sessions
Consider the following factors when choosing storage location for journey sessions.
| Server-side journey sessions | Client-side journey sessions | In-memory journey sessions | |
|---|---|---|---|
Session location |
Authoritative source: CTS token store. Sessions might also be cached in AM’s memory for improved performance. |
On the client. No CTS storage or replication overheads. |
In AM server’s memory. |
Load balancer requirements |
None. Session stickiness recommended for performance. |
None. Session stickiness recommended for performance. |
Session stickiness. |
Core token service usage |
Authoritative source for authenticated sessions. Session allowlisting, when enabled. |
Session allowlisting, when enabled. |
None. |
Uninterrupted session availability |
No special configuration required. |
No special configuration required. |
Not available. |
Session security |
Sessions reside in the CTS token store, and are not accessible to users. |
Sessions reside on the client and should be signed and encrypted. |
Sessions reside in AM’s memory, and are not accessible to users. |
Where to store authenticated sessions
Consider the following factors when choosing storage location for authenticated sessions.
| Server-side authenticated sessions | Client-side authenticated sessions | |
|---|---|---|
Hardware |
Higher I/O and memory consumption. |
Higher CPU consumption. |
Logical hosts |
Variable or large number of hosts. |
Variable or large number of hosts. |
Session monitoring |
Available. |
Not available. |
Session location |
Authoritative source: CTS token store. Authenticated sessions could also be cached in AM’s memory for improved performance. |
In a cookie in the client. |
Load balancer requirements |
None. Session stickiness recommended for performance. |
None. Session stickiness recommended for performance. |
Uninterrupted session availability |
No special configuration required. |
No special configuration required. |
Core token service usage |
Authoritative source for authenticated sessions. |
Provides session denylisting for logged out sessions. |
Core token service demand |
Heavier. |
Lighter. |
Session security |
Authenticated sessions reside in the CTS token store, and aren’t accessible to users. |
Authenticated sessions should be signed and encrypted.(1) |
Cross-domain single sign-on support |
All AM capabilities supported. |
Web agents and Java agents: Supported without restricted tokens. |
(1) Web agents and Java agents support either signing or encrypting client-side sessions, but not both. Learn more in Client-side session security and agents.