Client-side sessions are those where AM returns the session state to the client after a request, which then needs to be passed in with each subsequent request.
You should configure AM to sign and/or encrypt client-side sessions and client-side authentication sessions for security reasons. As decrypting and verifying the session may be an expensive operation to perform on each request, AM caches the decrypt sequence in memory to improve performance.
Client-side authentication sessions are configured by default.
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, AM creates the user’s session in the CTS token store or as a client-side session, depending on the session configuration for the realm. For realms configured for server-side sessions, AM will then attempt 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.
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.
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, see Session termination.