What is cookie bloat in ASP.NET Core and how does ITicketStore fix it?

Cookie bloat occurs when an identity payload expands due to heavy user claims profiles, groups, and permission flags, causing the HTTP request header to exceed server limits. The ITicketStore interface externalizes the full serialized ticket payload to a server-side repository like NCache, returning only a small session reference key token back to the browser client cookie.

Why is an out-of-process distributed cache required for an enterprise ITicketStore implementation?

Standard in-memory stores are volatile and isolated to a single server instance, losing all user sessions during restarts and requiring complex sticky session setups. A distributed cluster cache provider like NCache offers data high availability across load-balanced environments and permits seamless linear scalability as user traffic grows.

How are session timeouts and sliding expirations synchronized with the NCache cluster?

The custom provider intercepts the authentication middleware lifecycle events. When a sliding threshold is calculated as passed, the store triggers a runtime renew command against NCache, which updates the record's sliding eviction window and ensures cluster nodes reset their internal TTL states in perfect synchronization with cookie settings.

ASP.NET Core ITicketStore with NCache

In ASP.NET Core, cookie authentication is the standard mechanism used to manage user sessions. By default, when a user logs in, the framework serializes their entire identity including claims, roles, security stamps, and authentication metadata into an AuthenticationTicket. This ticket is encrypted, base64-encoded, and sent back to the browser as a cookie payload.

As applications grow, claims profiles (structured collections of digital identity attributes issued by an authentication authority) often expand to include deep enterprise metadata, group memberships, and permission flags. This leads to cookie bloat, where the HTTP request header grows excessively large, causing network overhead or getting rejected by web servers due to size limits.

The ITicketStore interface solves this by shifting the authentication session state from the client to a server-side repository. When implemented, the full AuthenticationTicket payload is externalized to a backend store, and only a lightweight, unique reference token (a session key) is sent to the client browser inside the cookie.

Note

This feature is supported only in the NCache OpenSource edition.

Important

ITicketStore is supported in NCache OSS 5.3.6.2 and later.

Why Use NCache as an ASP.NET Core ITicketStore Provider?

While a simple in-memory repository (like MemoryCacheTicketStore) works for a standalone instance, it fails in enterprise environments. In-memory data is volatile and tied to a single machine, meaning server restarts log out all active users, and load-balanced environments require complex sticky session setups.

Using NCache as the distributed backend for your ITicketStore bridges this gap by providing an out-of-process, highly available cache cluster. It offers several architectural advantages:

Elimination of Sticky Sessions: Since all load-balanced web app instances communicate with the same NCache cluster, a user can hit any server node on subsequent requests and remain seamlessly authenticated.
Resilience and High Availability: NCache's clustered topologies (such as Partitioned-Replica) ensure that session tickets are duplicated across multiple nodes. If a caching server goes down, sessions are not lost.
Linear Scalability: As the volume of active concurrent users grows, you can dynamically add nodes to the NCache cluster to handle the increased transaction throughput without degrading authentication performance.

Key Features

Integrating NCache as your server-side session backend yields critical performance and operational features:

Cookie Minimization: Reduces the authentication cookie to a fixed, minimal size (a unique string key), ensuring optimal HTTP request header performance.
Enhanced Session Security: Keeps sensitive user claims graphs within your secure, server-side data infrastructure rather than transmitting them back and forth over the wire to the client browser.
Dynamic Session Invalidation: Provides the ability to instantly terminate a user's session globally across the entire web farm by programmatically evicting their key from the NCache cluster (e.g., during forced password resets or administrative lockouts).
Native Serialization Compatibility: Integrates smoothly with ASP.NET Core’s native binary TicketSerializer, safely handling complex object graphs inside ClaimsPrincipal that frequently choke text-based JSON engines.
Flexible Expiration Synchronization: Inherits NCache’s advanced TTL (Time-to-Live) mechanisms, allowing the distributed cluster to automatically synchronize absolute or sliding eviction windows with the cookie middleware's configuration.

How TicketStore Works with NCache

The ITicketStore integration acts as a mediator between the ASP.NET Core authentication middleware and the NCache cluster APIs. The transactional lifecycle maps out through four fundamental operations:

Client Sign-In (Write Operation): When a user authenticates successfully via your application's login logic, HttpContext.SignInAsync() is triggered.

The cookie middleware creates the AuthenticationTicket.
Instead of writing the ticket into the browser cookie, the middleware invokes ITicketStore.StoreAsync(ticket).
The custom store creates a uniquely identifiable, namespaced session key (e.g., AuthSessionStore-guid).
The store serializes the ticket into a binary payload using the framework's native TicketSerializer and writes it to the NCache cluster using direct cache client operations (_cache.Insert).
The unique key string is sent back to the browser inside a lightweight cookie.

Subsequent Requests (Read Operation): For every subsequent incoming HTTP request to a protected endpoint, the browser sends the session key cookie.

The cookie middleware extracts the session key and passes it to ITicketStore.RetrieveAsync(key).
The store executes a direct read query against the NCache cluster (_cache.Get).
If a cache match is found, the binary data is deserialized back into a full AuthenticationTicket object, rehydrating the ClaimsPrincipal onto HttpContext.User.
If a cache miss occurs (due to manual eviction or timeout expiration), the store returns null, causing the middleware to seamlessly redirect the user to the login challenge page.

Sliding Expiration (Renew Operation)

If the application is configured to use sliding expiration rules:

As long as requests continuously flow through the application (such as polling a /ping endpoint), the cookie middleware calculates whether the sliding threshold window has passed.
When triggered, it invokes ITicketStore.RenewAsync(key, ticket) containing the updated expiration metrics.
The store updates the ticket information and updates the corresponding record inside NCache, resetting the TTL window on the cluster nodes to keep the user active.

Client Sign-Out (Remove Operation): When a user clicks log out, the application triggers HttpContext.SignOutAsync().

The middleware bypasses client-side state modifications and explicitly calls ITicketStore.RemoveAsync(key).
The store directly commands the NCache cluster to execute a removal operation (_cache.Remove), instantly tearing down the authenticated identity record across all distributed cluster nodes.

In This Section

NCache as ITicketStore Provider
Learn how to set up the prerequisites, implement the custom ITicketStore SDK architecture, and register the provider in your application.