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 journey and authenticated 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.
|
Find information about configuring AM with sticky load balancing in Load balancing. |
Find information about configuring client-side security in 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 aren’t 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 features aren’t supported or have limited support for client-side journey sessions and authenticated sessions:
| Functionality | Details |
|---|---|
Not supported |
|
Not supported |
|
Not supported for web and Java agents |
|
Not supported for web and Java agents |
|
Not supported for web and Java agents |
|
Not supported for journey sessions. Supported for authenticated sessions. |
|
Not supported |
|
Limited support |
Client-side journey sessions
Client-side journey sessions are configured by default in new installations.
While progressing through the authentication tree, the journey session state is returned to the client
after each call to the authenticate endpoint and stored in the authId object of the JSON response.
If the realm the user authenticated to is configured for server-side authenticated sessions, AM creates the authenticated session in the CTS token store when the journey completes.
Storing journey sessions on the client allows any AM server to handle the journey at any point in time without load balancing requirements.
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.
Client-side authenticated 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. Find more information about session cookies in Session cookies and session security.
Session denylisting is an optional feature that maintains a list of logged out client-side authenticated sessions in the CTS token store. Find more information about session termination and session denylisting in Session termination.
A user is granted a client-side journey session while they are completing the authentication tree.
If session denylisting is enabled, this journey session is "logged out" when the tree is completed, to prevent
replay attacks. This "logging out" adds the journey 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 journey session.
|
Learn more in Choose where to store sessions.