PingAM 7.5.1

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.

For information about configuring AM with sticky load balancing, refer to Load balancing.

If the session request is redirected to an AM server that does not 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 does not have the user’s 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 does not 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 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 both server-side authentication sessions and 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.

Server-side authentication sessions

Server-side authentication sessions are supported for authentication trees only.

During authentication, 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 authenticating user’s session in the CTS token store. After the authentication flow has completed, if the realm to which the user has authenticated is configured for client-side sessions, AM returns session state to the client and deletes the server-side session.

Authentication session allowlisting is an optional feature that maintains a list of in-progress authentication sessions and their progress in the authentication flow to protect against replay attacks. For more information, refer to Authentication session allowlisting.

Server-side 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.

For more information about session cookies, refer to Session cookies and session security.

Related information: Choose where to store sessions