Last Updated on September 15, 2025 by Aram
Many developers are stuck in 1 or 2 types of authorization in ASP.NET Core: simple and RBAC.
But did you know there are 5 more types of authorization in ASP.NET Core Web API?
This article represents a summarized view for all types of authorization in ASP.NET Core Web API, with a clear description on each type, when and how to use each one.
I am also providing a brief code sample to showcase the difference on how to use each authorization type in ASP.NET Core project.
And I will be highlighting each authorization type separately in the upcoming blog newsletters.
Introduction
Authorization is the process of verifying the permissions and access of an authenticated user or client
It ensures your API is secure and that users only access what they’re permitted to.
If a user is not allowed to access a certain resource because for instance their role doesn’t concern with the action they are trying to do , or they are from a different department, then a normal API response would be 403 forbidden.
On the contrary, if the user is unknown or provided wrong credentials, and tried to access a protected API, then they will get a 401 unauthorized response.
401 unauthorized vs 403 forbidden
401 unauthorized can be represented in a conversational style as: “I don’t know who you are, or I can’t verify your identity with what you’ve provided, so I cannot determine if you are authorized to access this resource.” It prompts the client to provide valid authentication.
In contrast, a 403 Forbidden status code indicates that the server knows who you are (you are authenticated), but you do not have the necessary permissions (authorization) to access the requested resource. The server understands your identity but denies access based on your privileges.
In ASP.NET Core Web API, authorization is flexible and can be applied at different levels, such as controllers, actions, or even resources, using attributes, policies, and custom logic.
Authorization helps enforce security and business rules by defining roles, claims, and policies that guide access decisions.
So, let’s explore the 7 Types of Authorization in ASP.NET Core Web API
1. Simple Authorization
This is the default and the most basic form of authorization
Using only the [Authorize] attribute on any controller would enable the simple authorization on it.
This means that any authenticated user is able to access that endpoint providing their access token
Can be used for generic purposes like (e.g., access to their profile screen)
|
1 2 3 4 |
// Program.cs builder.Services.AddAuthorization(); app.MapGet("/simple", [Authorize()] () => "You are authorized"); |
2. Role-based Authorization (RBAC)
Grants access based on user roles (e.g., Admin, Manager, User).
Roles are usually stored in JWT claims, Identity DB, or external providers.
You can use it Restrict admin dashboards or Limit critical API actions (e.g., deleting records).
|
1 2 3 |
builder.Services.AddAuthorization(); app.MapGet("/admin", [Authorize(Roles = "Admin")] () => "Welcome Admin!"); |
3. Policy-based Authorization (PBAC)
Policies are named sets of requirements.
Use this when access rules go beyond a simple role check (e.g., “Only Admins OR Managers”).
Policy-based authorization is the most flexible and powerful way to handle access control in ASP.NET Core.
Instead of hardcoding roles, you define policies with one or more requirements, and the framework checks if the user meets them.
You can combine multiple rules (roles, claims, assertions).
|
1 2 3 4 5 6 7 8 |
builder.Services.AddAuthorization(options => { options.AddPolicy("RequireAdminRole", policy => policy.RequireRole("Admin")); }); app.MapGet("/admin", [Authorize(Policy = "RequireAdminRole")] () => "Welcome, Admin! This endpoint is protected by policy-based authorization."); |
4. Claims-based Authorization (CBAC)
A claim is simply a key–value pair that describes something about the user.
This type of authorization authorizes users based on claims in their identity (e.g., EmployeeId, Department).
Use this when permissions depend on attributes of the user, like employee records, region, or subscription tier.
When a user logs in (via cookies, JWT, OpenID Connect, etc.), the system issues an identity containing claims.
These claims become part of the ClaimsPrincipal available in HttpContext.User.
ASP.NET Core authorization checks these claims against defined rules (policies).
|
1 2 3 4 5 6 7 8 9 10 11 |
builder.Services.AddAuthorization(options => { options.AddPolicy("EmployeeIdPolicy", policy => policy.RequireClaim("EmployeeId")); }); app.MapGet("/employee", [Authorize(Policy = "EmployeeIdPolicy")] (HttpContext ctx) => { var employeeId = ctx.User.FindFirst("EmployeeId")?.Value; return $"Hello Employee {employeeId}! This endpoint is protected by a claim-based policy."; }); |
5. Custom Requirement Authorization (CRA)
Here you create your own requirement and handler logic.
The Requirement will implement the IRequirementHandler, and then implement a custom authorization Handler for that requirement
This type can be useful when built-in checks (roles/claims) are not enough, like “User must be 18 years old” or “User must own > 5 projects.”
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
public class MinimumAgeRequirement : IAuthorizationRequirement { public int Age { get; } public MinimumAgeRequirement(int age) => Age = age; } public class MinimumAgeHandler : AuthorizationHandler<MinimumAgeRequirement> { protected override Task HandleRequirementAsync( AuthorizationHandlerContext context, MinimumAgeRequirement requirement) { var claim = context.User.FindFirst("DateOfBirth"); if (claim != null && DateTime.TryParse(claim.Value, out var dob)) { var age = DateTime.Today.Year - dob.Year; if (dob > DateTime.Today.AddYears(-age)) age--; if (age >= requirement.Age) context.Succeed(requirement); } return Task.CompletedTask; } } builder.Services.AddAuthorization(options => { options.AddPolicy("MinimumAge", policy => policy.Requirements.Add(new MinimumAgeRequirement(18))); }); builder.Services.AddSingleton<IAuthorizationHandler, MinimumAgeHandler>(); app.MapGet("/min-age", [Authorize(Policy = "MinimumAge")] () => "You meet the minimum age requirement!"); |
6. Endpoint-specific Authorization (ESA)
Instead of using attributes, you apply authorization directly on the endpoint in the pipeline.
Use this when dynamically adding routes or applying policies conditionally.
Useful in APIs that build routes at runtime.
|
1 2 3 4 5 6 7 8 |
builder.Services.AddAuthorization(options => { options.AddPolicy("RequireAdmin", policy => policy.RequireRole("Admin")); }); app.MapGet("/endpoint-auth", () => "Endpoint auth works!") .RequireAuthorization("RequireAdmin"); |
7. Resource-based Authorization
Authorizes access to a specific resource.
You compare the current user with the resource they’re trying to access.
This is useful for fine-grained control: e.g., user can only edit their own document, not someone else’s.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
builder.Services.AddAuthorization(options => { options.AddPolicy("DocumentAccessPolicy", policy => policy.RequireAssertion(ctx => { if (ctx.Resource is Document doc) { // Allow if user has "Manager" role if (ctx.User.IsInRole("Manager")) return true; // Allow if user owns the document var userId = ctx.User.FindFirst("UserId")?.Value; return userId == doc.OwnerId; } return false; })); }); var documents = new List<Document> { new("doc1", "user1", "Document 1 content"), new("doc2", "user2", "Document 2 content") }; app.MapGet("/documents/{id}", async (string id, IAuthorizationService auth, HttpContext ctx) => { var document = documents.FirstOrDefault(d => d.Id == id); if (document is null) return Results.NotFound(); var result = await auth.AuthorizeAsync(ctx.User, document, "DocumentAccessPolicy"); return result.Succeeded ? Results.Ok(document.Content) : Results.Forbid(); }); public record Document(string Id, string OwnerId, string Content); |
Final Thoughts
Authorization in ASP.NET Core Web API offers multiple approaches, from simple authentication checks to advanced resource-based rules.
By combining these techniques, you can secure your APIs at different levels, whether through roles, claims, policies, or custom requirements, and ensure users only access what they’re permitted to.
So here are the 7 types of Authorization in ASP.NET Core Web API:
- Simple
- Role-based
- Policy-based
- Claims-based
- Custom-requirement
- Endpoint-specific
- Resource-specific
So it is going to be a long but an exciting journey to learn in-depth about each type of authorization in ASP.NET Core Web API.
And if you follow my newsletters, you will be the first to learn about each type with a step-by-step tutorial, complete code examples, and output screenshots.
References
Introduction to authorization in ASP.NET Core
Previous Articles
Structured Logging in ASP.NET Core
Options Pattern in ASP.NET Core
ASP.NET Core Data Protection API
Bonus
Enjoy this wonderful masterpiece
Johann Pachebel – Canon in D By Jacob’s Piano