Introduction to sessions and cookies
AM uses two types of tokens that represent an exchange of information, usually interactive, between AM and a user or entity:
-
Authentication sessions, which AM uses to manage authentication journeys before a user has authenticated successfully.
-
Sessions, which AM creates after a user has authenticated successfully. Sessions let AM manage the user’s or entity’s access to resources.
Sessions and cookies
Sessions require the user or client to be able to hold on to cookies.
AM issues a cookie to the user or entity at the beginning of an authentication journey. This cookie corresponds to an authentication session.
AM issues another cookie to the user or entity after successful authentication. This cookie corresponds to a session.
The content in these cookies differs depending on the session type and location.
Session location
Both authentication sessions and sessions can be stored on the client or on the server.
Sessions stored on the server are called server-side sessions. Server-side sessions are stored in a database internal to AM called the Core Token Service (CTS) token store.
Sessions stored on the client are called client-side sessions. Client-side sessions are stored in the session cookie.
Regardless of the session location, AM issues a cookie to the user or entity; however, the content in the session cookies differs depending on the session’s location:
-
Server-side sessions contain a reference to the session’s location in the CTS token store and several other pieces of information. The details about server-side sessions are maintained in the CTS token store.
-
Client-side session cookies contain all the details about the session.
Because server-side sessions only contain references to the locations where the session details are stored, while client-side cookies contain all the details about sessions, client-side session cookies are significantly larger than server-side session cookies.
Session location is configurable by realm in AM. The following table illustrates where AM can store sessions:
| In the CTS token store | On the client | |
|---|---|---|
Authentication sessions |
✔ |
✔ (Default) |
Sessions |
✔ (Default) |
✔ |
Session storage location can be heterogeneous within the same AM deployment to suit the requirements of each of your realms.
For more information about configuring session locations, refer to:
Session cookie name
AM provides a unique, pseudo-random session cookie name for each tenant.
Throughout the AM documentation, the tenant session cookie name is
referred to as <session-cookie-name> to denote this generated value.
-
In the Identity Cloud admin UI, open the Tenant menu (upper right).
-
Select Tenant Settings.
-
Select Global Settings.
-
View or copy the Cookie field value. This is used in HTTP header values in AM API requests; for example, in the OAuth 2.0 authorization grant flow.
Authentication session allowlist
Authentication session allowlisting is an optional feature that maintains a list of in-progress authentication sessions and their progress in the authentication flow to protect against replay attacks.
For more information about the allowlisting setting, refer to Trees.