Choosing 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-based authentication sessions and CTS-based sessions if it suits your environment.

AM stores CTS-based 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 CTS-Based Sessions

Advantage	Applies to Authentication Sessions?	Applies to Sessions?
Full Feature Support CTS-based sessions support all AM features, such as CDSSO and quotas. Client-based sessions do not. For information about restrictions on AM usage with client-based sessions, see Limitations When Using Client-Based Sessions. This advantage does not apply to authentication sessions, since they do not provide features.		
Session Information Is Not Resident In Browser Cookies With CTS-based sessions, all the information about the session resides in CTS and might be cached on one or more AM servers. With client-based sessions, session information is held in browser cookies. This information could be very long-lived.		

Advantages of Client-Based Sessions

Advantage	Applies to Authentication Sessions?	Applies to Sessions?
Unlimited Horizontal Scalability for Session Infrastructure Client-based 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-based 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-based sessions are not constrained by the replication speed of the CTS token store. Therefore, client-based 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-based or CTS-based 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-based sessions, authentication session information is held in browser cookies.		

Impact of Storage Location for Authentication Sessions

	CTS-Based Authentication Sessions	Client-Based 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 whitelisting, when enabled.	Session whitelisting, 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

	CTS-Based Sessions	Client-Based 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 blacklisting 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. ^[a]
Cross-Domain Single Sign-On Support	All AM capabilities supported.	Web Agents and Java Agents: Supported without restricted tokens.
^[a] Web Agents and Java Agents support either signing or encrypting client-based sessions, but not both. For more information, see "Client-Based Session Security and Agents".