An authorization decision determines whether a user may access an application feature. Authentication comes first: credentials establish who the user is; authorization then decides whether that identity is entitled to use the feature. ASP.NET Core Identity supplies authentication, while ASP.NET Core authorization features enforce access restrictions. section 39.2 section 1.1.4
Protect an endpoint with the `Authorize` attribute and let the built-in middleware enforce the restriction. The attribute can be applied to a Razor Page model, a controller, or the page model for a Blazor application's entry point. Protecting the Blazor entry point prevents unauthenticated users from entering the application; access to individual components is a separate option. section 39.0 section 39.4
Listing 39.22 Applying an attribute in the DataController.cs file in the Controllers folder of the Advanced project
using Advanced.Models;
using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
using Microsoft.AspNetCore.Authorization;
namespace Advanced.Controllers {
[ApiController]
[Route("/api/people")]
[Authorize]
public class DataController : ControllerBase {
private DataContext context;
// ...methods omitted for brevity...
}
}
The controller-level `[Authorize]` attribute restricts the `/api/people` web-service endpoints without adding checks to each action. section 39.5.2
Observe the decision
Request `/users/list` while signed out: the browser shows a login prompt. Sign in as `bob` with password `secret`: the authenticated user is denied access. Sign out and repeat with `admin` and `secret`: the user belongs to the role required by the `Authorize` attribute, so the Razor Page appears. A signed-out JavaScript client requesting a protected web-service endpoint instead receives `401 Unauthorized`. section 39.3.5 section 39.5.2
For cookie-based browser requests, `CookieAuthenticationOptions` can change where an unauthenticated user is sent to log in (`LoginPath`) and where an authenticated but unauthorized user is sent (`AccessDeniedPath`). These are different failures; sending both users to the same place would hide a useful clue when testing access. section 39.3.5
