Browser Session Cookies Do Not Fit in a Native App: A Mechanism Account of ASP.NET Core Chunked Cookies and SecurityStamp

Cookie authentication was designed for the browser. That sounds like a truism, but hidden behind it is a chain of implicit premises: a cookie has a size ceiling, credentials can be revoked server-side, and the client has an atomic, jar-level-consistent cookie store. The browser satisfies all three, and satisfies them so naturally that we almost never stop to think they exist.

When a React Native app uses the operating system's native cookie store to consume that same cookie authentication, all three premises crack at once. What this post wants to dissect is not a single bug, but how three normally quiet mechanisms inside ASP.NET Core cookie auth — chunking, SecurityStamp validation, and client-side cookie storage semantics — interlock once they step outside the browser abstraction boundary, amplifying a harmless default into a fatal failure path. Once you have the mechanism account of all three, you can anticipate this class of problem instead of debugging it after the fact.

Mechanism one: why "chunked cookies" exist

A single HTTP cookie has a size ceiling. The spec mandates no specific number, but browsers and servers commonly keep a single cookie in the 4KB range; exceed it and the cookie is silently dropped.

For an ASP.NET Core Identity authentication ticket, that is a real problem. The ticket holds more than a session id — it is a self-contained encrypted envelope: security stamp, name, email, role, and other claims, serialized, handed to Data Protection for encryption, then Base64URL-encoded, and finally wrapped with the __Host- prefix. The more claims, the larger the envelope. A real ticket pushing past 4KB is not unusual at all.

ASP.NET Core's answer is ChunkingCookieManager (enabled by default, with ChunkSize = 4090). Its strategy is straightforward: when the ticket exceeds the single-chunk ceiling, it splits the value into cookie, cookieC1, cookieC2, … and writes those chunks out, reassembling them by index on read.

There is a detail here that is easy to overlook, and it is exactly the crux of the story that follows: when the number of chunks changes — say this ticket needs 3 chunks while last time only 2 were needed — ChunkingCookieManager does not merely write the new chunks; it also emits deletion-style Set-Cookie headers for the chunks no longer needed (setting their expiry to epoch). In other words, "rewriting a chunked cookie once" is, at the protocol level, a group of Set-Cookie directives that must be applied as a whole: some writing, some deleting. The browser lands that group atomically into its cookie jar, no question about it. Hold on to that word "atomic" — it is the setup for the third mechanism.

Mechanism two: SecurityStamp validation, and the ValidationInterval knob

The second mechanism answers a security question: once a cookie has been issued, how do you invalidate it before it naturally expires?

Identity's answer is the security stamp. Each user has a stamp value in the database, and that stamp is imprinted into the ticket when the cookie is issued. When a user changes their password — or you explicitly call UpdateSecurityStampAsync — the stamp in the database changes, so every cookie carrying the old stamp fails on its next validation. This is the underlying mechanism that makes "changing your password kicks out all other devices" hold.

But validation has a cost — it means comparing the stamp in the ticket against the stamp in the database. If every request hit the database, authentication would become a performance bottleneck. So the framework gives you a knob: SecurityStampValidatorOptions.ValidationInterval. Its semantics are "only re-validate the stamp once more than this interval has passed since the last validation." The default is 30 minutes. This knob is essentially a trade-off between revocation latency and validation cost: turn it down and stamp changes propagate faster, but per-request cost rises; turn it up and cost drops, but an invalidated cookie may survive up to one interval longer.

The crucial causal chain is here: whenever stamp validation actually runs and decides the ticket needs refreshing, ShouldRenew is set to true, and the framework re-issues the cookie — emitting another group of Set-Cookie headers. Normally this happens only once every 30 minutes, and no one notices.

But what if someone set ValidationInterval to TimeSpan.Zero? The semantics become "validate on every request," so every request triggers ShouldRenew, and every request re-emits the entire group of chunked cookies. In a browser this is at most a little wasted bandwidth — because the browser atomically lands each re-emitted group into the jar, and the state stays self-consistent. Note that "harmless in the browser" conclusion; the third mechanism is about to overturn it.

Mechanism three: native cookie storage is not a browser cookie jar

The browser's cookie jar has two properties we take for granted and rarely spell out: it understands the atomicity of a group of Set-Cookie directives, and it maintains jar-level consistency. A group of "write C1/C2, delete C3" directives either takes effect as a whole or not at all; there is never an intermediate torn state of "new C1 paired with old C3."

The native app uses something entirely different. Take a library like react-native-nitro-cookies: it is essentially a stateless mirror of the operating system's cookie store — underneath sits iOS's NSHTTPCookieStorage or Android's CookieManager. These native stores manage cookies one at a time, by name. They do not know that app-auth, app-authC1, and app-authC2 belong semantically to the same ticket, and they certainly do not treat the multiple Set-Cookie headers in one response (including the deletion-style ones) as a single unit to be applied atomically.

So the crack appears: when the server re-emits this whole multi-chunk cookie set on every request, and the chunk count is also changing (so the emission carries deletion-style directives), the native mirror has no ability to atomically replace the set as a whole. One replacement may write the new low-index chunks but fail to correctly clear the leftover high-index chunks. Stale chunks accumulate, and the next request carries a ticket that is already corrupt after reassembly to the server. The server fails to decrypt the ticket (Unprotect) — and fails extremely fast, returning a 401 in roughly 0.1ms. An active session, seconds after login, gets a 401 out of nowhere.

Where the three premises intersect

Stack the three mechanisms together and the failure becomes a structural inevitability, not an accidental bug:

ValidationInterval = TimeSpan.Zero (mechanism two) → re-emit chunked __Host- cookies on every request (mechanism one) → the native mirror cannot atomically replace the multi-chunk set (mechanism three) → stale chunks accumulate → the next request's ticket is corrupt after reassembly → server decryption fails → a ~0.1ms 401 inside an active session.

What is worth savoring is that each mechanism, taken alone, is not wrong. Chunking exists to fit a large ticket; per-request validation exists for instant revocation; the native mirror is the standard way mobile accesses system cookies. What is wrong is the implicit premise no one re-examined at their intersection: the value TimeSpan.Zero was chosen under a worldview where "the client is a browser and the cookie jar is atomic." Once the client becomes a native app, that premise no longer holds, and the default flips from "harmless" to "fatal."

This also explains why this class of problem is so disorienting to debug: the symptom (an active session dropping its login) looks like a persistence problem or a cold-start problem, and pulls you toward "extend MaxAge" or "retry on cold start" — orthogonal axes. Each of those may be a correct fix in its own right, but none of them touch the real failure axis: the chunk-reassembly race inside an active session. When a fix has no effect, rather than piling on another patch, the faster question to ask is "which axis is it actually fixing?"

The fix, and the design judgments it exposes

The direct fix is a single line — return ValidationInterval to a finite and large enough value, so cookies stop being re-emitted on every request:

services.Configure<SecurityStampValidatorOptions>(opt =>
{
    // Must be a finite value. As long as mobile still consumes chunked __Host- cookies
    // through the native cookie mirror, TimeSpan.Zero is forbidden — it re-emits chunked
    // cookies on every request and triggers the reassembly race on the native side.
    opt.ValidationInterval = TimeSpan.FromMinutes(30);
});

But more important than that one line are the design judgments it forces into the open:

The revocation-latency trade-off should be made explicit, not forced by twisting a knob. A finite interval means "invalidating an issued cookie" (password change, UpdateSecurityStampAsync) propagates only after up to 30 minutes. If the business genuinely needs near-instant revocation, the correct path is to switch to a mechanism that does not re-emit chunked cookies on every request — for instance, use a server-side ITicketStore to persist tickets server-side with only a reference left in the cookie, or just move mobile to bearer-token authentication — and not to drive the interval toward zero. Driving the interval to zero in pursuit of instant revocation is precisely what re-treads this failure path.

Some revocations should not depend on this interval at all. Account disabled, permission/role change, explicit logout — if these are resolved live from the database on every request (rather than read from cookie claims), they take effect instantly by nature, completely sidestepping the interval's latency. This in turn gives a design rule: keep cookie claims minimal. Stuffing mutable information like role and email into the ticket not only makes authorization depend on a stale snapshot, it also bloats the ticket and increases the chunk count — and in the native-app scenario, a larger ticket means a higher probability of the chunk-reassembly race. Leaving mutable authorization information to per-request DB resolution, with the cookie carrying identity only, is a win-win.

Contracts that cross an abstraction boundary should be cast into an executable regression guard. The constraint "ValidationInterval must be finite" cannot be held by a comment — the next person could perfectly well twist it back to zero for some other need. What actually blocks the regression is an integration test: after login, assert that a subsequent GET /users/me returns 200 and carries no Set-Cookie. That "no re-emission" assertion is the gatekeeper of this whole mechanism account — the moment someone revives the churn, it goes red.

The transferable layer

Set aside the specific .NET and RN APIs, and the real transferable insight from this case is:

An abstraction designed for one runtime environment freezes that environment's implicit premises into its defaults. When you move the abstraction to a new environment (browser → native app, single-machine → distributed, sync → concurrent), the most dangerous thing is usually not the obvious incompatibilities, but these defaults that look like they keep working while their premise has quietly failed. Cookie auth "basically running" inside the app is exactly this kind of dangerous disguise.

When debugging this class of problem, instead of hunting through each mechanism for which one broke, flip the question: under what premises was this set of mechanisms originally designed, and do I still satisfy those premises? When each mechanism is individually correct but the combination misbehaves, it is almost always because some premise quietly collapsed at the boundary.