Server-Side Sessions

(added in 6.1)


When a user logs in interactively, their authentication session is managed by the ASP.NET Core authentication system, and more specifically the cookie authentication handler. IdentityServer uses the state in the cookie to track the user’s subject and session identifiers (i.e. the sub and sid claims), and the list of clients the user has logged into (which is used at logout time for OIDC logout notification).

By default, this cookie is self-contained which means it contains all the state needed to track a user’s session. While this does allow for a stateless server for session management, cookie size could be a problem, and it makes it difficult to know how many active user sessions there are in your system or revoke those sessions from an administrative standpoint.

IdentityServer provides a server-side session feature, which extends the ASP.NET Core cookie authentication handler to maintain this state in a server-side store, rather than putting it all into the cookie itself. This implementation is specifically designed for IdentityServer to allow for more protocol related features, such as querying for active sessions based on subject id or session id, and revoking artifacts from protocol workflows as part of that session.

Support for Server Side Sessions is included in IdentityServer Business Edition or higher.

Session Management

With the addition and use of server-side sessions, more interesting architectural features are possible:

  • the ability to query and manage sessions from outside the browser that a user is logged into.
  • the ability to detect session expiration and perform cleanup both in IdentityServer as well as in the client.
  • the ability to centralize and monitor session activity in order to achieve a system-wide inactivity timeout.

Enabling server-side sessions

To enable server-side sessions, use the AddServerSideSessions extension method after adding IdentityServer to the DI system:


By default, the store for the server-side sessions will just be kept in-memory. For production scenarios you will want to configure a durable store either by using our EntityFramework Core implementation, or you can implement the store yourself.

Order is important in the DI system. When using AddServerSideSessions, this call needs to come after any custom IRefreshTokenService implementation that has been registered.

Data stored server-side

The data stored for the user session is the data contained in the ASP.NET Core AuthenticationTicket class. This includes all claims and the AuthenticationProperties.Items collection. The Items can be used to store any custom (string) data. The AuthenticationProperties is included in the call to SignInAsync that establishes the user session in the UI code.

This data will be serialized and protected using ASP.NET Core’s data protection feature to protect any user PII from being directly readable in the data store. To allow querying some of the values from the user’s session are extracted and used as indices in the store. These values are the user’s:

  • subject identifier (the sub claim value)
  • session identifier (the sid claim value)
  • display name (an optional and configurable claim value)

If you would like to query this data based on a user’s display name, then the claim type used is configurable with the ServerSideSessions.UserDisplayNameClaimType property on the IdentityServerOptions. This claim must be included in the claims when the user’s authentication session is established.

For example:

builder.Services.AddIdentityServer(options => {
    options.ServerSideSessions.UserDisplayNameClaimType = "name"; // or "email" perhaps


The IServerSideSessionStore is the abstraction for storing the server-side session.

A EntityFramework Core implementaiton is already provided as part of our operational store, but you can implement the interface yourself for other backing implementations.