ASP.NET Core Identity with JWT and cookie authentication both sit on the same Identity user store, yet they answer completely different deployment questions. Cookies are managed by the browser and sent automatically with every request, which makes them natural for server-rendered pages and Blazor Server applications. JWT bearer tokens travel in Authorization headers and scale cleanly across REST APIs, mobile clients, and background services. Choosing between them — or combining them — comes down to how your .NET 10 application is actually used.
ASP.NET Core Identity with JWT and Cookies Compared
The most visible difference is where the credential lives. A cookie is a browser-held session identifier or ticket that the framework re-validates, typically against server-side session state. A JWT is a self-contained, signed token that the API validates by signature alone. That single difference cascades into everything else: where you can revoke access, what you must defend against, and who can consume the credential.
- Storage: cookies live in the browser and need no special handling in JS; JWTs must be stored by the client and attached manually to every request.
- Revocation: cookies can be invalidated instantly on the server; a JWT stays valid until it expires unless you add a revocation layer.
- CSRF: cookie-based auth must defend against cross-site request forgery; bearer tokens in headers are not sent automatically, so CSRF is mostly moot.
- Consumers: cookies work for browsers; JWTs work for browsers, mobile apps, desktop clients, and API-to-API calls.
Both mechanisms sit on top of the same ASP.NET Core Identity user store, so the user management, password policy, and lockout behavior are identical. What changes is the transport of the authentication proof.
The choice is rarely about Identity itself — the user store, password hashing, and lockout rules are identical either way. The choice is about the audience: a browser sitting in front of a server-rendered app, or a heterogeneous set of clients calling an API. Naming the audience is the fastest way to pick a side.
The Blazor Server SignalR Factor
Blazor Server is a special case because the interactive UI runs over a SignalR connection, not plain HTTP. SignalR negotiates a connection, and if the app requires authentication, the initial negotiate request must carry the credential. A cookie is included automatically by the browser, so SignalR connections just work. With a JWT, you must configure AccessTokenProvider to send the token on the negotiate request — one extra moving part that is easy to get wrong.
For a pure Blazor Server application with no external API consumers, cookie authentication is the path of least resistance and the recommended default. It also integrates cleanly with the framework's built-in redirect-to-login behavior and antiforgery validation.
Making JWT work with Blazor Server is not much harder, but it is fiddly. You register an AccessTokenProvider that supplies the bearer token to SignalR during connection negotiation, and the server uses it to establish the authenticated circuit. That extra step pays for itself when the same backend also exposes a REST API, because you implement the security model once and every consumer uses the same token.
When Cookie Authentication Wins
Choose cookies when your audience is exclusively a browser, when you want instant server-side revocation, or when you prefer the framework to handle login redirects and antiforgery for you. The configuration is minimal:
builder.Services
.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
.AddCookie(options =>
{
options.LoginPath = "/login";
options.Cookie.HttpOnly = true;
options.Cookie.SecurePolicy = CookieSecurePolicy.Always;
options.ExpireTimeSpan = TimeSpan.FromHours(8);
options.SlidingExpiration = true;
});The HttpOnly flag keeps JavaScript away from the cookie, SecurePolicy.Always forces HTTPS, and SlidingExpiration keeps active users signed in while idle sessions expire. This covers most internal admin systems built with Blazor Server alone.
Cookie authentication also composes with Identity's built-in UI, so registration pages, external logins, and two-factor flows ship without custom token plumbing. For a single-tenant admin system or an intranet tool, that low-friction experience is hard to beat — secure sessions with a dozen lines of configuration.
Choosing ASP.NET Core Identity with JWT for the REST API Layer
Choose ASP.NET Core Identity with JWT when the same backend must serve a REST API consumed by mobile apps, SPAs, or other services — the classic shape of an Indotalent product, where a Blazor Server UI and a full API ship in one solution. JWT lets every consumer authenticate independently, keeps the API stateless, and delegates to roles and claims for authorization. You can even run both schemes side by side: cookies authenticate the Blazor UI over SignalR, and the API endpoints authenticate with bearer tokens.
Bearer tokens also travel cleanly through proxies and CDNs because they are not tied to a browser origin, which matters when your API sits behind an API gateway or load balancer. The statelessness of JWT validation makes horizontal scaling trivial: any instance can validate any token as long as it shares the signing key and the same issuer and audience settings.
The hybrid costs a little extra configuration, but it gives you the best of both worlds: effortless browser sessions and a genuinely reusable API. Whatever you choose, keep the Identity store authoritative for users and passwords, and remember that security flags like HttpOnly and SecurePolicy matter just as much for JWT cookies in SPAs.
Start by registering both schemes in the authentication pipeline. Cookie authentication becomes the default for browser-facing routes and the Blazor Server circuit, while JWT is configured as an additional scheme that API endpoints opt into by grouping endpoints under MapGroup().RequireAuthorization("Bearer"). The Identity store, password rules, and lockout behavior stay shared, so users experience one account with two ways to present their credentials.
Key Takeaways
- Cookies fit browser-only Blazor Server apps; JWT fits REST APIs with multiple consumer types
- SignalR makes cookies effortless for Blazor Server, while JWT requires an access token provider on negotiate
- Cookies give instant revocation; JWT needs short lifetimes plus refresh token rotation
- A hybrid setup — cookies for the UI, JWT for the API — covers most production .NET 10 apps
- Indotalent products demonstrate the hybrid pattern with ASP.NET Core Identity in real code
FAQ
Is cookie authentication secure for Blazor Server? Yes, with HttpOnly, Secure, SameSite, and antiforgery enabled. Blazor Server apps use a persistent SignalR connection, and the framework protects it with the standard cookie pipeline.
Can I use ASP.NET Core Identity with JWT for Blazor Server? Absolutely — many apps do. You just configure an access token provider so SignalR sends the bearer token during connection negotiation.
Why is CSRF a concern with cookies but not with JWT in headers? Browsers attach cookies automatically to every request, so a malicious site could trigger authenticated actions. Bearer tokens in Authorization headers must be added explicitly, so forged requests carry no token.
Should I run both authentication schemes at once? Yes, it is a common and well-supported pattern: register cookie authentication for the interactive UI and JWT for the REST API, each on its own route or endpoint group.