Server-side sessions
Server-side sessions reside in the CTS token store and can be cached in memory on one or more AM servers to improve system performance.
|
Find information about configuring AM with sticky load balancing in Load balancing. |
If the session request is redirected to an AM server that doesn’t have the session cached, that server must retrieve the session from the CTS token store.
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 doesn’t have the session cached, the AM server retrieves the session from the CTS token store, incurring performance overhead.
AM sends a reference to the session to the client, but the reference doesn’t contain any of the session state information. AM can modify a session during its lifetime without changing the client’s reference to the session.
Advantages of server-side sessions
- Full feature support
-
Server-side sessions support all AM features, such as CDSSO and quotas. Client-side sessions don’t. Learn more in Limitations of client-side sessions.
This advantage doesn’t apply to journey sessions because they don’t provide these features. - Session information isn’t resident in browser cookies
-
With both server-side journey sessions and authenticated sessions, all the information about the session resides in the CTS and could be cached on one or more AM servers. With client-side authenticated sessions, session information is held in browser cookies. This information could be very long-lived.
Server-side journey sessions
While progressing through the authentication tree, the session reference is returned to the client after a call to the authenticate endpoint
and stored in the authId object of the JSON response.
AM maintains the journey session in the CTS token store. After the journey has completed, AM returns session state to the client and deletes the server-side authenticated session if the realm to which the user has authenticated is configured for client-side authenticated sessions.
Journey session allowlisting is an optional feature that maintains a list of in-progress journey sessions and their progress in the journey to protect against replay attacks. Learn more in Journey session allowlisting.
Server-side authenticated sessions
Once the user is authenticated, the session reference is known as an SSO token.
For browser clients, AM sets a cookie in the browser that contains the session reference.
For REST clients, AM returns the session reference in response to calls to the authentication endpoint.
Learn more in Session cookies and session security.
Related information: Choose where to store sessions