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:
-
Cross-domain single sign-on with restricted tokens (web agents and Java agents)
-
Session signing and encryption (web agents and Java agents)
-
Uncompressed sessions (web agents and Java agents)
(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