Access Management 7.4.1

Client-side sessions

For client-side sessions, AM returns the session state to the client after each request and requires the session state to be passed in with the subsequent request.

For security reasons, you should configure AM to sign and/or encrypt client-side sessions and client-side authentication sessions. Decrypting and verifying the session can be an expensive operation to perform on each request. AM therefore caches the decrypt sequence in memory to improve performance.

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

For more information about configuring client-side security, refer to Client-side session security.

Advantages of client-side sessions

Unlimited horizontal scalability for session infrastructure

Client-side sessions provide unlimited horizontal scalability 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 stores synchronized 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.

Limitations of client-side sessions

The following limitations in functionality apply to client-side authentication sessions and sessions:

(1) Limitation only applies to authenticated sessions

(2) Reduced functionality

Client-side authentication sessions

Client-side authentication sessions are supported for authentication trees only, and are configured by default in new installations.

During authentication, the authentication session state is returned to the client after each call to the authenticate endpoint and stored in the authId object of the JSON response.

After the authentication flow has completed, if the realm to which the user has authenticated is configured for server-side sessions, AM creates the user’s session in the CTS token store. Then, AM attempts to invalidate the client-side authentication session.

Storing authentication sessions on the client allows any AM server to handle the authentication flow at any point in time without load balancing requirements.

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.

Client-side sessions

For browser-based clients, AM sets a cookie in the browser that contains the session state. When the browser transmits the cookie back to AM, AM decodes the session state from the cookie. For REST-based clients, AM sends the cookie in a header. For more information about session cookies, refer to Session cookies and session security.

Session denylisting is an optional feature that maintains a list of logged out client-side sessions in the CTS token store. For more information about session termination and session denylisting, refer to Session termination.

A user is granted a client-side authentication session while they are completing the authentication tree. If session denylisting is enabled, this authentication session is "logged out" when the tree is completed, to prevent replay attacks. This "logging out" adds the authentication session to the session denylist for client-side sessions. In the CTS store, this takes the form of a SESSION_BLACKLIST token that exists for the life of the authentication session.

Related information: Choose where to store sessions