JWT Revocation vs Session Cookie Revocation in .NET for Least-Privilege Authentication

Answer – Session Cookies with Server‑Side Store

In a .NET application that demands strict least‑privilege enforcement and the ability to revoke credentials instantly, the most balanced approach is to use stateful session cookies backed by a fast, shared store (Redis, in‑memory cache, SQL). Removing the session entry immediately invalidates every active cookie, giving you real‑time revocation without adding per‑request lookups. JWTs, while stateless, cannot be revoked until they expire unless you maintain a revocation list that is consulted on every request – this adds latency and complexity.

Why Session Cookies Win on Immediate Revocation

• Delete‑once‑and‑forget: revocation is a single store‑delete operation.
• Zero per‑request overhead: the authentication middleware simply checks the session key.
• Scalable with distributed caches: sharded Redis or replicated SQL keeps latency low even at high load.
• Built‑in support in ASP.NET Core: services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) and app.UseAuthentication() handle the plumbing.

When JWTs Can Still Be Used

If you must keep a stateless architecture (e.g., for serverless or CDN edge functions), you can mitigate the revocation window by:

1. Issuing very short‑lived access tokens (5‑15 min).
2. Storing refresh tokens in a server‑side session store and rotating them on each use.
3. Using a lightweight revocation list only for refresh tokens, not for access tokens.

This hybrid pattern gives you the performance of JWTs while retaining immediate revocation for the long‑lived refresh token.

Practical Steps for a Session‑Based Solution

1. Choose a store: Redis is the most common; add services.AddStackExchangeRedisCache().
2. Configure cookie auth:

   services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
           .AddCookie(options => {
               options.Cookie.HttpOnly = true;
               options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
               options.ExpireTimeSpan = TimeSpan.FromHours(1);
               options.SlidingExpiration = true;
           });

3. Implement revocation: When a credential is revoked, delete the session key:

   await cache.RemoveAsync(sessionId); // sessionId = HttpContext.Session.Id
   

4. Verify: After deletion, any request with the cookie will fail authentication and redirect to login.

Missing Diagnostic Detail

To confirm this recommendation, could you let me know if your deployment must remain completely stateless (no shared session store) or if a shared cache is acceptable? This will determine whether a pure JWT approach with a blacklist is viable.