Client-side sessions
AM creates sessions either as client-side sessions or server-side sessions. The session location depends on the session configuration.
Client-side sessions are those where AM returns the entire session state to the client after a request. AM returns the session state to the client in a session cookie. The cookie is then passed back to AM with each subsequent request.
Client-side authentication sessions
AM uses authentication sessions to manage authentication journeys before a user has authenticated successfully.
Authentication sessions are configured as client-side sessions 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.
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 realms configured for server-side sessions, AM attempts to invalidate client-side authentication sessions after creating the server-side sessions.
Client-side sessions
AM creates sessions after users' authentication flow have completed successfully.
For browser-based clients that use client-side sessions, 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.
Secure client-side sessions
It’s a best practice to configure AM to sign and/or encrypt client-side sessions and client-side authentication sessions for security reasons. Because decrypting and verifying the session can be an expensive operation to perform on each request, AM caches the decrypt sequence in memory to improve performance.