Authentication (AuthN) establishes a user's identity from credentials, such as a username and password. Authorization (AuthZ) comes afterward: it decides whether that identified user may access a feature. A valid login does not, by itself, grant access to every endpoint. section 39.2 section 39.3.5
In ASP.NET Core, Identity manages users and validates credentials. A login action can receive UserManager<IdentityUser> and SignInManager<IdentityUser> through its constructor. The GET action displays the credential form and preserves a return URL; the POST action checks the submitted credentials. On failure, it displays a validation error. On success, it signs the user in and redirects to the requested URL. section 11.4 section 38.5
Follow authentication through the request flow:
- A request for a protected endpoint without an authenticated user leads to the login prompt; cookie options can change the default /Account/Login path. section 39.3.5
- A successful sign-in usually creates an Identity cookie that accompanies subsequent requests. Logging out removes it. section 39.6 section 39.2.4
- After login, authorization still checks access. A signed-in user without the required role sees access denied; a user with that role reaches the page. section 39.3.5
Check the result in a browser
Create a user, sign in at /account/login, and visit /account/details to observe the Identity cookie. Visit /account/logout, then return to /account/details to confirm it has been deleted. For a restricted /users/list page, try both a user without the required role and one with it: the first is denied after login; the second reaches the page. section 39.2.4 section 39.3.5
...
builder.Services.Configure<CookieAuthenticationOptions>(
IdentityConstants.ApplicationScheme,
opts => {
opts.LoginPath = "/Authenticate";
opts.AccessDeniedPath = "/NotAllowed";
});
...
The cookie options listing changes where an unauthenticated browser is sent to log in and where an authenticated but unauthorized browser is sent instead. section 39.3.5
The same boundary can protect a Blazor application at its _Host entry page with [Authorize]. Web services and JavaScript clients can use cookie authentication or bearer tokens instead. Do not put real credentials in client-side JavaScript merely to make a demo convenient; and do not move credential verification into the client. section 39.4 section 39.6 section 39.5.1 section 11.4
