Session cookies and session security

Authenticated sessions require the user or client to be able to hold on to cookies. Cookies provided by AM’s Session Service can contain a JSON Web Token (JWT) with the session or just a reference to where the session is stored.

AM issues a cookie to the user or entity regardless of the session location for client-side and server-side sessions. By default, the cookie’s name is iPlanetDirectoryPro. For authenticated sessions stored in the CTS token store, the cookie contains a reference to the session in the CTS token store and several other pieces of information. For authenticated sessions stored on the client, the iPlanetDirectoryPro cookie contains all the information that would be held in the CTS token store.

Client-side session cookies consist of two parts: The first part of the cookie is identical to the cookie used by server-side sessions, which ensures the compatibility of the cookies regardless of the session location. The second part is a JSON Web Token (JWT), which contains session information, as illustrated below:

Note that the examples are not to scale. The size of the client-side session cookie increases when you customize AM to store additional attributes in users' sessions. You’re responsible for ensuring the size of the cookie doesn’t exceed the maximum cookie size allowed by your end users' browsers.

Since the session cookie is either a pointer to the authenticated session or the actual session itself, you must configure AM to secure the session cookie against hijacking, session tampering, and other security concerns.

For example, terminating a session effectively logs the user or entity out of all realms, but the way AM terminates sessions has security implications depending on where AM stores the sessions. You can also configure the session time-to-live, idle timeout, the number of concurrent sessions for a user, and others.

Related information: