Introduction

In ASP.NET MVC, the [Authorize] attribute restricts access to controllers and actions based on authentication and roles. When applied at the controller level, it affects all actions. To exempt specific actions, use [AllowAnonymous]. To change authorization rules for a single action, apply a more specific [Authorize] with different roles. For complex scenarios, create a custom AuthorizeAttribute subclass that overrides AuthorizeCore or HandleUnauthorizedRequest. In ASP.NET Core, the approach shifts to policy-based authorization with [Authorize(Policy = "...")].

Default Authorize Behavior

1// All actions in this controller require authentication
2[Authorize]
3public class AdminController : Controller
4{
5    public ActionResult Dashboard()
6    {
7        return View();  // Requires any authenticated user
8    }
9
10    public ActionResult Settings()
11    {
12        return View();  // Also requires authentication
13    }
14}

When [Authorize] is on the controller, every action inherits that requirement. The attribute checks HttpContext.User.Identity.IsAuthenticated and optionally verifies roles.

AllowAnonymous to Bypass Authorization

1[Authorize]
2public class AccountController : Controller
3{
4    public ActionResult Profile()
5    {
6        return View();  // Requires authentication
7    }
8
9    [AllowAnonymous]
10    public ActionResult Login()
11    {
12        return View();  // Accessible without authentication
13    }
14
15    [AllowAnonymous]
16    public ActionResult Register()
17    {
18        return View();  // Accessible without authentication
19    }
20}

[AllowAnonymous] overrides [Authorize] at the controller level. The MVC framework checks for AllowAnonymous before evaluating Authorize, so it effectively exempts specific actions.

Override with Different Roles

1[Authorize(Roles = "User,Admin")]
2public class DashboardController : Controller
3{
4    public ActionResult Index()
5    {
6        return View();  // Any User or Admin
7    }
8
9    [Authorize(Roles = "Admin")]
10    public ActionResult ManageUsers()
11    {
12        return View();  // Only Admin — more restrictive
13    }
14}

When [Authorize] appears on both the controller and an action, both are evaluated. The action-level attribute does not replace the controller-level one — it adds an additional requirement. A user must satisfy both constraints.

Custom AuthorizeAttribute

1public class CustomAuthorizeAttribute : AuthorizeAttribute
2{
3    public string Permission { get; set; }
4
5    protected override bool AuthorizeCore(HttpContextBase httpContext)
6    {
7        if (!base.AuthorizeCore(httpContext))
8            return false;
9
10        // Custom logic: check specific permission
11        var user = httpContext.User;
12        if (string.IsNullOrEmpty(Permission))
13            return true;
14
15        // Check permission from claims or database
16        return user.HasClaim("Permission", Permission);
17    }
18
19    protected override void HandleUnauthorizedRequest(
20        AuthorizationContext filterContext)
21    {
22        if (filterContext.HttpContext.User.Identity.IsAuthenticated)
23        {
24            // User is logged in but lacks permission — show 403
25            filterContext.Result = new HttpStatusCodeResult(403);
26        }
27        else
28        {
29            // Not authenticated — redirect to login
30            base.HandleUnauthorizedRequest(filterContext);
31        }
32    }
33}
34
35// Usage
36[CustomAuthorize(Permission = "EditPosts")]
37public ActionResult EditPost(int id)
38{
39    return View();
40}

Override AuthorizeCore for custom authorization logic and HandleUnauthorizedRequest to control what happens when authorization fails. This distinguishes between "not logged in" (401) and "logged in but forbidden" (403).

Global Filter with Action Override

1// Global filter in FilterConfig.cs
2public class FilterConfig
3{
4    public static void RegisterGlobalFilters(GlobalFilterCollection filters)
5    {
6        filters.Add(new AuthorizeAttribute());  // Require auth everywhere
7    }
8}
9
10// Controller can use AllowAnonymous to opt out
11public class HomeController : Controller
12{
13    [AllowAnonymous]
14    public ActionResult Index()
15    {
16        return View();  // Public page
17    }
18}

Registering [Authorize] as a global filter enforces authentication on every action by default. Individual actions opt out with [AllowAnonymous].

OverrideAuthorization Attribute (MVC 5)

1// MVC 5 introduced OverrideAuthorization
2[Authorize(Roles = "User,Admin")]
3public class ReportController : Controller
4{
5    public ActionResult ViewReport()
6    {
7        return View();  // Requires User or Admin
8    }
9
10    [OverrideAuthorization]
11    [Authorize(Roles = "Admin")]
12    public ActionResult DeleteReport()
13    {
14        return View();  // Only Admin — replaces controller-level auth
15    }
16}

[OverrideAuthorization] tells MVC to ignore the controller-level [Authorize] and only apply the action-level one. Without it, both [Authorize] attributes would be evaluated together (AND logic).

ASP.NET Core Policy-Based Authorization

1// Startup.cs / Program.cs
2builder.Services.AddAuthorization(options =>
3{
4    options.AddPolicy("AdminOnly", policy =>
5        policy.RequireRole("Admin"));
6
7    options.AddPolicy("CanEditPosts", policy =>
8        policy.RequireClaim("Permission", "EditPosts"));
9});
10
11// Controller
12[Authorize(Policy = "CanEditPosts")]
13public class PostController : ControllerBase
14{
15    [HttpGet]
16    public IActionResult GetPosts() => Ok();
17
18    [Authorize(Policy = "AdminOnly")]
19    [HttpDelete("{id}")]
20    public IActionResult DeletePost(int id) => Ok();
21
22    [AllowAnonymous]
23    [HttpGet("public")]
24    public IActionResult PublicPosts() => Ok();
25}

ASP.NET Core replaces role-based [Authorize] with policies. Policies encapsulate complex authorization requirements (roles, claims, custom handlers) into named rules.

Common Pitfalls

• Assuming action-level [Authorize] replaces controller-level: Without [OverrideAuthorization] (MVC 5), both attributes are evaluated with AND logic. An action with [Authorize(Roles = "Admin")] under a controller with [Authorize(Roles = "User")] requires both roles, not just Admin.
• Returning 401 instead of 403 for authorized users: The default HandleUnauthorizedRequest redirects to the login page even for authenticated users who lack permission. Override it to return 403 Forbidden when the user is already logged in.
• Not registering AllowAnonymous in the pipeline: In ASP.NET Core, AllowAnonymous only works if UseAuthorization() middleware is registered. Missing middleware means the attribute is silently ignored and all requests pass through.
• Mixing ASP.NET MVC and Core authorization: ASP.NET MVC uses System.Web.Mvc.AuthorizeAttribute and overrides AuthorizeCore. ASP.NET Core uses Microsoft.AspNetCore.Authorization.AuthorizeAttribute with IAuthorizationHandler. The APIs are incompatible.
• Global [Authorize] blocking health check and API endpoints: When using a global filter, forgetting [AllowAnonymous] on health check, login, and public API endpoints causes them to require authentication, breaking monitoring tools and user access flows.

Summary

• Use [AllowAnonymous] to exempt specific actions from controller-level [Authorize]
• Action-level [Authorize] adds to (not replaces) controller-level authorization by default
• Use [OverrideAuthorization] (MVC 5) to replace controller-level auth at the action level
• Create custom AuthorizeAttribute subclasses for permission-based or claims-based logic
• Override HandleUnauthorizedRequest to distinguish 401 (not logged in) from 403 (forbidden)
• In ASP.NET Core, use policy-based authorization with named policies for cleaner configuration