In-memory sessions
In-memory sessions reside in AM’s memory. AM sends clients a reference to the session, but the reference doesn’t contain any of the session state information.
Advantages of in-memory sessions
- Faster performance with equivalent host
-
AM servers configured for in-memory journey sessions can validate more sessions per second per host than those configured for client-side or server-side journey sessions.
- Session information isn’t in browser cookies
-
Journey session information resides in AM’s memory, and isn’t accessible to users. With client-side sessions, journey session information is held in browser cookies.
In-memory journey sessions
In-memory journey sessions are configured by default after an upgrade.
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.
AM maintains the user’s journey session in its memory. After the journey has completed, AM performs the following tasks:
-
If the realm to which the user has authenticated is configured for server-side authenticated sessions, AM stores the authenticated session in the CTS token store and deletes the journey session from memory.
-
If the realm to which the user has authenticated is configured for client-side authenticated sessions, AM stores the authenticated session in a cookie on the user’s browser and deletes the journey session from memory.
Journey session allowlisting is an optional feature that maintains a list of in-progress journey sessions and their progress in the authentication flow to protect against replay attacks. Learn more in Journey session allowlisting.
|
Deployments where AM stores journey sessions in memory require sticky load balancing to route all requests for a specific journey to the same AM server. If a request reaches a different AM server, the journey starts again. Find information about configuring AM with sticky load balancing in Load balancing. |