7 Types of Authorization in ASP.NET Core

The simplest form: mark a controller, action, or minimal API route with [Authorize] (or .RequireAuthorization()) so only authenticated users can access it. No roles, no custom rules — just "must be logged in."

Use this for endpoints that any signed-in user may call: profile page, logout, generic dashboard shell. Anonymous users get 401 Unauthorized (not authenticated) or 403 Forbidden (authenticated but not allowed), depending on the failure mode.

Register authentication first (AddAuthentication + middleware). Authorization without authentication only checks an empty principal — a common misconfiguration in new projects.

Role-based authorization checks membership in named roles: Admin, Editor, Viewer. In ASP.NET Core, roles are typically role claims on the user's identity (ClaimTypes.Role or "role" in JWT).

Decorate with [Authorize(Roles = "Admin")] or multiple roles (comma = OR). Works well when permissions align with job titles and stay coarse — back-office apps, internal tools, small teams.

Breaks down when one user needs exceptions ("Editor except billing") or when role names explode (AdminBilling, AdminSupport, …). That is when policies and claims take over.

Policies name a bundle of requirements. Instead of scattering role strings, you register options.AddPolicy("CanManageUsers", …) once and reference [Authorize(Policy = "CanManageUsers")] everywhere.

Policies can require roles, claims, custom requirements, or combinations via PolicyBuilder. Central registration in Program.cs keeps authorization rules discoverable and testable — one file to audit before release.

This is the recommended default for production APIs once you outgrow bare roles.

Claims are key-value facts about the user: user ID, email, permission=invoice.approve, tenant_id=42. Claims-based authorization checks those facts instead of roles alone.

Use RequireClaim("permission", "reports.export") inside a policy, or [Authorize(Policy = "ExportReports")] where the policy requires that claim. JWT access tokens commonly carry permissions as claims; Identity adds them at sign-in.

This maps cleanly to permission tables in the database without creating a new role per combination.

When built-in rules are not enough, implement IAuthorizationRequirement and AuthorizationHandler<TRequirement>. The handler contains your logic: database lookups, business rules, time windows, subscription tier checks.

Register the requirement in a policy with policy.AddRequirements(...), and register its handler with dependency injection. Every distinct requirement in a policy must succeed (AND). If one requirement has multiple handlers, any handler may satisfy that requirement (OR); there is no UseRequireAll switch.

This is how authorization stays domain-aware without bloating controllers.

Endpoint-specific authorization applies different rules per route — critical for Minimal APIs and for mixing public, authenticated, and admin routes in one app.

Patterns: [Authorize] on one controller action but not another; .RequireAuthorization("PolicyName") on a single MapGet; route groups with app.MapGroup("/admin").RequireAuthorization(). You can also use IEndpointConventionBuilder metadata and endpoint filters in .NET 7+.

Fine-grained HTTP method control: GET public, POST requires Editor — implement via separate endpoints or policy per verb.

Resource-based authorization asks: "Can this user perform this action on this document?" Roles and claims alone cannot answer that — ownership and row-level rules depend on the resource instance.

Call IAuthorizationService.AuthorizeAsync(user, resource, policyName) in your handler after loading the entity. Common pattern: user may edit only their own orders; managers may edit team orders; admins may edit all.

Implement OperationAuthorizationRequirement or a custom requirement where the handler receives the resource object (Order, Document, Project).

Use the simplest model that fits — then upgrade when pain appears.

Start: [Authorize] on everything except login/register.Add RBAC when job titles map cleanly to access.Move to policies + claims when permissions multiply.Add custom handlers when rules need database or domain logic.Apply per-endpoint when public and protected routes mix in one API.Add resource checks when users share a system but own different rows.

Most production ASP.NET Core APIs combine types: policies with claim requirements on endpoints, plus resource authorization in command handlers for update/delete.