liveBook · Manning

Authorize attribute

As explained in Building Web APIs with ASP.NET Core

AuthorizeAttribute is an ASP.NET Core attribute that declares authorization requirements for a controller, action, or endpoint handler.

`[Authorize]` declares who may call an ASP.NET Core controller, action method, minimal API handler, or gRPC service method. In a board-game API, it protects operations that change stored data while leaving read-only operations available without signing in. Add `using Microsoft.AspNetCore.Authorization;`, then place the attribute on each operation that needs protection. With no parameters, it requires an authenticated user; it does not distinguish that user’s permissions. section 9.3.2 section 10.3.6

Choose where the rule belongs:

  • Place `[Authorize]` on individual update, delete, or seed actions to protect only those actions. This is a default-allow approach: actions without the attribute remain open to anonymous callers. section 9.3.2
  • Place it on a controller when that controller as a whole should require authorization, rather than marking each action separately. section 9.3.2
  • Set `Roles = RoleNames.Moderator` on update actions or `Roles = RoleNames.Administrator` on delete and seed operations when authentication alone is too broad. The user’s JWT must contain a matching role claim for that check. section 9.4.5 section 9.4.7

Protect and test a board-game update

Put `[Authorize]` above the board-game `Post` action to require sign-in, or use `[Authorize(Roles = RoleNames.Moderator)]` to require the Moderator role. For a safe first test, call a protected `/auth/test/1` GET endpoint in SwaggerUI without a token: expect `401 Unauthorized`. Log in, copy the JWT into SwaggerUI’s Authorize dialog, and call it again before the token expires: expect `200 OK` and “You are authorized!” The first test checks the restriction; the second checks the bearer-token flow. section 9.3.2 section 9.3.3 section 9.4.5

For requirements beyond roles, register an authorization policy and name it with `[Authorize(Policy = "ModeratorWithMobilePhone")]`. That example policy requires both a Moderator role claim and a mobile-phone claim; supplying the phone value also requires changes to registration, storage, and JWT creation. The same attribute can protect a gRPC board-game update method. To make SwaggerUI’s padlocks reflect actual restrictions, an operation filter can inspect endpoint metadata for `AuthorizeAttribute` instead of marking every endpoint as secured. section 9.4.7 section 10.3.6 section 11.3.1

builder.Services.AddAuthorization(options => 
{
    options.AddPolicy("ModeratorWithMobilePhone", policy =>
        policy
            .RequireClaim(ClaimTypes.Role, RoleNames.Moderator)#1
            .RequireClaim(ClaimTypes.MobilePhone));             #2
});

The policy registration shows how the named policy combines a role claim with a mobile-phone claim before an action references it. section 9.4.7

How Building Web APIs with ASP.NET Core covers it

How deep it goes
Works through attribute placement, authentication tests, role parameters, and a policy example; does not implement the mobile-phone policy end to end.
Examples
Uses protected board-game updates, a SwaggerUI GET test returning 401 then 200, and a Moderator-plus-mobile-phone policy.
What it assumes
Assumes an existing ASP.NET Core API and login flow; introduces the parameterless authorization check before adding roles and claims.
What you can do after
Apply it via ASP.NET Core attributes to protect endpoints by authentication, role, or named policy, then verify bearer-token access in SwaggerUI.
How it connects
Connects JWT bearer authentication and role-based access control to claims-based policies, gRPC authorization, and SwaggerUI security requirements.

Also explained in

Compare how 3 books explain authorize attribute →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Building Web APIs with ASP.NET Core. The section links point to the parts of the book it draws on.