liveBook · Manning

Cookie

As explained in ASP.NET Core in Action, 3e

An authentication cookie is a client-side HTTP cookie containing serialized authentication state used to recognize a signed-in user across requests.

An authentication cookie lets a traditional web app recognize a signed-in user on later requests. After a successful sign-in, the app sends the browser an encrypted cookie containing a serialized ClaimsPrincipal. The browser sends it automatically on subsequent requests. section 25.1.1

In an ASP.NET Core app, the flow has three parts:

  • A user submits a sign-in form. SignInManager validates the credentials and creates the signed-in principal. section 23.1.2
  • The principal—not the IdentityUser database entity—is serialized into the authentication cookie. section 23.3.3
  • On the next request, AuthenticationMiddleware decodes the cookie, deserializes and validates the principal, and sets the current user. section 25.1.1
Figure 23.2 Signing in to an ASP.NET Core application. SignInManager is responsible for setting HttpContext.User to the new principal and serializing the principal to the encrypted cookie.
CH23_F02_Lock3

The sign-in diagram connects the form submission, SignInManager, the current request’s user, and the encrypted cookie returned to the browser. section 23.1.2

A cookie identifies the user; it does not grant every permission. In a traditional Razor Pages app, an unauthenticated request to a protected page redirects to sign-in. A signed-in user who lacks permission redirects to an access-denied page. section 24.2.2

Why automatic sending matters

Suppose a signed-in user visits a malicious site containing a form that POSTs to a banking app. The browser may send the bank’s authentication cookie with that request, making it appear to come from the user. Antiforgery tokens help the app reject the forged submission. Razor Pages enables antiforgery checks by default; take care before disabling them. section 29.2

Protect authentication cookies by preventing JavaScript from reading them, sending them only over HTTPS, and using SameSite=Strict where possible. Cookies suit a single traditional web app, but can be awkward for mobile clients or requests spanning multiple domains; API clients commonly send tokens instead. section 29.4.4 section 25.1.1 section 24.2.2

How ASP.NET Core in Action, 3e covers it

How deep it goes
Works through sign-in, principal serialization, and subsequent-request validation, then addresses authorization responses and CSRF risk.
Examples
Uses a Razor Pages sign-in flow and a forged bank-transfer form to illustrate normal behavior and risk.
What it assumes
Starts with email-and-password sign-in and introduces the principal through an ASP.NET Core request flow.
What you can do after
Evaluate/understand it by tracing how a signed-in principal reaches later requests and distinguishing it from the database user entity.
How it connects
Connects ClaimsPrincipal, ASP.NET Core Identity, AuthenticationMiddleware, authorization, and antiforgery tokens.

Also explained in

Compare how 10 books explain cookie →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of ASP.NET Core in Action, 3e. The section links point to the parts of the book it draws on.