ASP.NET Core authentication and authorization

Two questions, never one. Authentication answers who the caller is and hands you a ClaimsPrincipal. Authorization answers what that principal may do. The framework keeps them as separate middlewares - UseAuthentication() then UseAuthorization(), in that order - and so should your thinking. A 401 means the framework could not establish identity; a 403 means it knows who you are and the answer is still no.

Floor is .NET 10 / C# 14; .NET 8 / 9 are past support from 2026-11-10 - deltas below the floor are marked. On .NET Framework 4.8 the OWIN / Katana + ASP.NET Identity 2.x auth stack is in references/net-framework-48.md.

When to use

• ASP.NET Core authentication (who the caller is) and authorization (what they may do). Also fires on: standing up a sign-in flow, an authorization handler, protecting an endpoint.
• Do NOT load for the OWASP hardening sweep, secret placement, or crypto primitives - the .NET application-security and cryptography skills own those.

Pick the scheme from the surface

The right authentication scheme is decided by what kind of client talks to the endpoint, not by preference:

• Stateless REST API -> JWT bearer (Microsoft.AspNetCore.Authentication.JwtBearer). The token carries the identity; the server keeps no session.
• Server-rendered app (MVC, Razor Pages, Blazor Server) -> cookie authentication. The browser already holds a cookie; use it.
• Delegated identity / single sign-on -> OpenID Connect, with an external provider doing the actual sign-in.
• A service or webhook caller that cannot do a real handshake -> an API key, the weakest credential.