Knowing exactly who someone is settles nothing about what they're allowed to do next.

The previous lesson ended with a fully authenticated request: HttpContext.User holds a real, verified identity — say, a logged-in customer named Priya. Now a request comes in: DELETE /api/orders/4471. The server knows, with certainty, that this is Priya. That fact, on its own, answers nothing about whether this specific delete should be allowed. Is order 4471 even Priya's order? Is Priya an administrator who can delete any order, or an ordinary customer who can only delete her own, and only within an hour of placing it? Authentication already did its job perfectly — it told you who's asking. It was never going to tell you what they're allowed to do. That's a completely separate question, with a completely separate answer, and answering it is this lesson's entire subject.

In this lesson: [Authorize] and [AllowAnonymous], role-based authorization with [Authorize(Roles = "...")], the more flexible policy-based authorization model built around arbitrary requirements, and claims — the underlying currency that both authentication and authorization actually read and reason about.

What Is It?

The Simple Explanation

Authorization is the process of deciding whether an already-identified caller is permitted to perform a specific action or access a specific resource. It always runs after authentication, and it always assumes authentication already did its job — authorization never re-checks "is this really who they claim to be," it only ever asks "given that this is genuinely who they are, are they allowed to do this?"

The Technical Definition

In ASP.NET Core, authorization is implemented as middleware (UseAuthorization()) plus a set of attributes and services that evaluate one or more requirements against the current ClaimsPrincipal on HttpContext.User — the exact identity authentication produced in the previous lesson. The simplest requirement is "any authenticated identity" (bare [Authorize]); more specific requirements check role membership or evaluate an arbitrary, named policy. Every one of these checks ultimately reads claims — individual facts attached to the identity — to make its decision.

Why Does It Exist?

The Problem — Not Every Authenticated User Should Do Everything

Almost every real application has more than one kind of user, and different kinds of users are allowed to do genuinely different things — customers can view their own orders, but only staff can issue refunds; only an order's owner can cancel it; only an administrator can delete another user's account. If the only gate is "are you logged in at all," none of these distinctions can be expressed. Every authenticated user would be equally powerful, which is rarely the actual intent and is often a serious security gap.

The Need

What's needed is a way to express permission rules — sometimes as simple as "must be an Admin," sometimes as elaborate as "must be over 18 and from a supported region and own the resource being modified" — evaluated consistently, on every relevant request, without scattering ad-hoc if checks for role names or claim values throughout the codebase.

The Solution

ASP.NET Core's authorization system, offering three levels of expressiveness: bare [Authorize] for "any authenticated user," role-based [Authorize(Roles = "...")] for simple role membership checks, and policy-based authorization for arbitrary, named, reusable requirements — the most flexible of the three, and the one modern applications increasingly reach for as rules grow past "does this user have role X."

Big Picture

How It Works

[Authorize]
[HttpGet("me")]
public IActionResult GetMyProfile() => Ok(User.Identity?.Name);

[Authorize]                 // every action in this controller requires authentication...
public class AccountController : ControllerBase
{
    [AllowAnonymous]         // ...except this one, which explicitly opts back out
    [HttpPost("register")]
    public IActionResult Register(RegisterRequest request) { /* ... */ }
}

[Authorize(Roles = "Admin")]
[HttpDelete("{id}")]
public IActionResult DeleteUser(int id) { /* ... */ }

[Authorize(Roles = "Admin,Manager")]  // comma-separated = OR: either role is accepted
[HttpGet("reports")]
public IActionResult ViewReports() { /* ... */ }

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("MustBeOver18", policy =>
        policy.RequireAssertion(context =>
        {
            var dobClaim = context.User.FindFirst(c => c.Type == ClaimTypes.DateOfBirth);
            return dobClaim is not null
                && DateOnly.TryParse(dobClaim.Value, out var dob)
                && DateOnly.FromDateTime(DateTime.UtcNow) >= dob.AddYears(18);
        }));
});

[Authorize(Policy = "MustBeOver18")]
[HttpPost("purchase-restricted-item")]
public IActionResult PurchaseRestrictedItem() { /* ... */ }

Simple Example

Why policies are more flexible than roles alone — a rule that role-based authorization simply cannot express, because it isn't about role membership at all:

// "Must have completed onboarding AND be from a supported country" —
// this has nothing to do with role membership, so [Authorize(Roles = "...")] cannot express it at all.
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("CanPlaceOrders", policy =>
        policy.RequireClaim("onboarding_complete", "true")
              .RequireClaim("country", "US", "CA", "GB")); // any of these values satisfies the claim
});

Meaning: A role check can only ever ask "does this user have role X (or Y, or Z)?" A policy can ask anything expressible against the current ClaimsPrincipal — multiple claims combined together, custom logic via RequireAssertion, even injected services consulted mid-check via a custom IAuthorizationHandler. That's precisely why policies are described as more flexible: roles are really just one narrow, common special case of "a rule based on claims," and policies are the general mechanism roles happen to be built on top of internally.

Real-World Example

A support ticketing system with three genuinely distinct authorization needs on one controller:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("OwnsTicketOrIsSupportStaff", policy =>
        policy.RequireAssertion(context =>
        {
            if (context.User.IsInRole("Support") || context.User.IsInRole("Admin"))
                return true;

            // Otherwise, the caller must be the ticket's own creator — a rule tied to a specific
            // resource, which no role by itself could ever express.
            var ticketId = ((HttpContext)context.Resource!).Request.RouteValues["id"]?.ToString();
            var userId = context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value;
            return TicketOwnershipChecker.UserOwnsTicket(userId, ticketId);
        }));
});

[ApiController]
[Route("api/tickets")]
public class TicketsController : ControllerBase
{
    [AllowAnonymous]
    [HttpGet("public-status")]
    public IActionResult PublicSystemStatus() => Ok("All systems operational");

    [Authorize] // any authenticated user can create a ticket
    [HttpPost]
    public IActionResult CreateTicket(CreateTicketRequest request) { /* ... */ }

    [Authorize(Roles = "Support,Admin")] // simple role check — closing a ticket is support/admin only
    [HttpPost("{id}/close")]
    public IActionResult CloseTicket(int id) { /* ... */ }

    [Authorize(Policy = "OwnsTicketOrIsSupportStaff")] // needs richer, resource-aware logic than roles alone can express
    [HttpGet("{id}")]
    public IActionResult GetTicket(int id) { /* ... */ }
}

Notice all four authorization shapes side by side, on one controller: fully public ([AllowAnonymous]), any authenticated user ([Authorize]), simple role membership (Roles = "Support,Admin"), and a genuinely custom, resource-aware policy that no combination of role names alone could express — because the rule depends on which specific ticket is being requested, not just who the caller is in general.

Analogy

Under the Hood

Common Confusion

1. "Authorization is just another word for authentication" — no; this is the same conflation from the previous lesson, now from the other side

By this point in the pipeline, authentication has already run and already succeeded — the identity is settled. Authorization takes that settled identity as a given and asks a genuinely different question: not "is this real," but "is this allowed." If a request fails authorization (403), that never means the identity was invalid — it means the identity was perfectly valid and simply isn't permitted to do the thing it asked for.

2. "Roles and claims are different systems" — roles are just one specific kind of claim

Beginners sometimes treat "role-based" and "claims-based" as two competing authorization models. They're not — role membership is stored and read as an ordinary claim (typically ClaimTypes.Role), and [Authorize(Roles = "Admin")] is really a convenient, narrower shorthand over the same claims mechanism that policies use in general. Claims are the one underlying currency; roles are a specific, very common pattern built from that currency.

Common Mistakes

Mistake 1 — Using Roles = "Admin,Manager" and expecting an AND, not an OR

Assuming a comma-separated role list requires the caller to hold all listed roles at once.

It's an OR — any one of the listed roles is sufficient. If you genuinely need "must have both Role A and Role B," stack two separate [Authorize] attributes (ASP.NET Core requires all applied [Authorize] attributes to individually succeed), or express it explicitly as a policy.

Mistake 2 — Reaching for ever-more role names instead of a policy, as rules grow complex

Inventing roles like "AdminOver18" or "PremiumUSCustomer" purely to encode a rule that's really a combination of unrelated facts, bloating the role list with one-off, single-purpose entries.

Once a rule depends on more than plain role membership — age, region, resource ownership, a combination of several facts — express it as a policy instead of contorting the role system to fit.

Mistake 3 — Forgetting that [AllowAnonymous] is needed inside a controller-level [Authorize]

Applying [Authorize] at the controller level, then adding a login or registration action that has no way to reach an authenticated state yet — locking users out of the very endpoint that would authenticate them.

Explicitly mark those specific actions [AllowAnonymous] — it overrides the controller-level requirement for that action only.

When Should I Use It?

• Use bare [Authorize] when the only requirement is "any logged-in user" — a profile page, a "my orders" list.
• Use role-based authorization when the rule is genuinely just about coarse-grained membership in a fixed, small set of categories — "staff-only," "admin-only."
• Use policy-based authorization as soon as a rule needs anything beyond plain role membership — multiple conditions combined, resource ownership, age or region checks, custom logic that consults other data.
• Use [AllowAnonymous] for the deliberate, specific exceptions inside an otherwise-protected controller — never as a way to avoid thinking through whether an endpoint should really be public.

Mental Model

Key Takeaway

Check Your Understanding

You've seen how authorization builds on authentication's identity, and the three levels of expressiveness available. Let's check your understanding.

You now understand exactly how authentication and authorization divide the work — and how claims, roles, and policies fit together to express real permission rules. Next up: JWT, the concrete mechanism behind most modern token-based authentication.

dotnetmadeeasy.com — Learn C# and .NET, the right way.