Choose where to store sessions
You can configure authentication session storage location independently from session storage location. For example, you could configure the same realm for client-side authentication sessions and server-side sessions if it suits your environment.
AM stores server-side sessions in the CTS token store and caches sessions in server memory. If a server with cached sessions fails, or if the load balancer in front of AM servers directs a request to a server that does not have the user’s session cached, the AM server retrieves the session from the CTS token store, incurring performance overhead.
Choosing where to store sessions is an important decision you must make by realm. Consider the information in the following tables before configuring sessions:
Advantages of server-side sessions
| Advantage | Applies to authentication sessions? | Applies to sessions? |
|---|---|---|
Full feature support Server-side sessions support all AM features, such as CDSSO and quotas. Client-side sessions do not. For information about restrictions on AM usage with client-side sessions, refer to Limitations of client-side sessions. This advantage does not apply to authentication sessions, since they do not provide features. |
— |
✔ |
Session information is not resident in browser cookies With server-side sessions, all the information about the session resides in CTS and might be cached on one or more AM servers. With client-side sessions, session information is held in browser cookies. This information could be very long-lived. |
✔ |
✔ |
Advantages of client-side sessions
| Advantage | Applies to authentication sessions? | Applies to sessions? |
|---|---|---|
Unlimited horizontal scalability for session infrastructure Client-side sessions provides unlimited horizontal scalability for your sessions by storing the session state on the client as a signed and encrypted JWT. Overall performance on hosts using client-side sessions can be easily improved by adding more hosts to the AM deployment. |
✔ |
✔ |
Replication-free deployments Global deployments may struggle to keep their CTS token store replication in sync when distances are long and updates are frequent. Client-side sessions are not constrained by the replication speed of the CTS token store. Therefore, client-side sessions are usually more suitable for deployments where a session can be serviced at any time by any server. |
✔ |
✔ |
Advantages of in-memory sessions
| Advantage | Applies to Authentication Sessions? | Applies to Sessions? |
|---|---|---|
Faster performance with equivalent host AM servers configured for in-memory authentication sessions can validate more sessions per second per host than those configured for client-side or server-side authentication sessions. |
✔ |
✖ |
Session information is not resident in browser cookies Authentication session information resides in AM’s memory and it is not accessible to users. With client-side sessions, authentication session information is held in browser cookies. |
✔ |
✖ |
Impact of 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. |
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. |
Impact of 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.