Introduction to sessions
AM uses two types of tokens that represent an exchange of information, usually interactive, between AM and a user or identity:
-
Authentication sessions, which AM creates to track progress through an authentication tree or chain before the user has authenticated successfully.
-
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 do not 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 authentication sessions and 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 | |
|---|---|---|---|
Authentication sessions |
✔(1) |
✔(1) (Default in new installations) |
✔(2) (Default after upgrade) |
Sessions |
✔ (Default) |
✔ |
✖ |
(1) Authentication trees only.
(2) Available for authentication trees and authentication chains.
|
You can configure different session locations within the same AM deployment to suit the requirements of each realm. You can also configure authentication session location independently of session location. For example, you could configure the same realm for client-side authentication sessions and server-side 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 authentication sessions
Consider the following factors when choosing storage location for authentication sessions.
| Server-side authentication sessions | Client-side authentication sessions | In-memory authentication sessions | |
|---|---|---|---|
Authentication method |
Authentication trees. |
Authentication trees. |
Authentication trees and authentication chains. |
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 user 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 sessions
Consider the following factors when choosing storage location for sessions.
| Server-side sessions | Client-side 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. Sessions might 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 user sessions. |
Provides session denylisting for logged out sessions. |
Core token service demand |
Heavier. |
Lighter. |
Session security |
Sessions reside in the CTS token store, and are not accessible to users. |
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. For more information, refer to Client-side session security and agents.