Authentication determines who made a request. It comes before authorization, which decides whether that person may perform an action. A user can be authenticated without being allowed to access a particular feature. section 23.1 section 24.7
In ASP.NET Core, every request has a user principal available through HttpContext.User. Without authentication, that principal is anonymous. An authenticated principal can carry claims—individual pieces of information such as a user ID, name, email address, or access-related property. Razor Pages and views can read the current principal to adapt what they display. section 23.7
A typical sign-in flow in a traditional web app works like this:
- The user submits an identifier, such as an email address, and a secret, such as a password. The app checks them against a known user. section 23.1.2
- After a successful sign-in, the app sets the current principal and sends an encrypted cookie containing its serialized details. section 23.1.2 section 25.1.1
- On a later request, the browser sends the cookie automatically. Authentication middleware reads it and restores the principal for that request. section 25.1.1
Figure 23.3 A subsequent request after signing in to an application. The cookie sent with the request contains the user principal, which is validated and used to authenticate the request.
Follow the cookie on a request after sign-in to see how the app recognizes the returning user. section 23.1.2
ASP.NET Core Identity supplies user-management and sign-in services, including password storage; its default UI is available through Microsoft.AspNetCore.Identity.UI. AuthenticationMiddleware handles the request principal. If you place it explicitly with UseAuthentication(), put it before middleware that needs an authenticated user, such as UseAuthorization(). section 23.7
Cookies fit a single traditional web app well, but APIs and multiple applications can need a different arrangement. APIs typically authenticate using a header; bearer tokens, including JSON Web Tokens (JWTs), are an option. When several apps must recognize the same user, moving authentication responsibilities to a separate service avoids duplicating sign-in logic across them. section 24.1 section 25.1.1
