自定义IdentityHandler授权处理类的技术咨询

Great start on building a custom authorization handler with ASP.NET Core! Let's walk through your implementation, highlight key considerations, and share best practices to make it robust and aligned with the framework's design.

First, let's recap your code for clarity:

public class IdentityHandler<TRole> : AuthorizationHandler<IdentityRequirement<TRole>>, ITokenValidator where TRole : Role {
    protected AuthorizationHandlerContext AuthContext { get; private set; }
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IdentityRequirement<TRole> requirement) {
        AuthContext = context;
        //部分校验逻辑
        //若未满足要求则调用ThrowUnathorizedException()
        ...
    }
}

Key Observations & Improvements #

1. Avoid Storing AuthorizationHandlerContext as a Singleton Property #

Your AuthContext property caches the request-specific context, but here's the critical gotcha: authorization handlers are typically registered as singletons in ASP.NET Core. That means multiple concurrent requests will overwrite this property, causing race conditions where one request's context leaks into another. This leads to unpredictable authorization results and hard-to-trace bugs.

Fix: Instead of storing the context, pass it directly to any helper methods you need in the handler. For example:

protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, IdentityRequirement<TRole> requirement) {
    // Pass context directly to your token validation method
    if (!ValidateToken(context, requirement)) {
        context.Fail();
        return Task.CompletedTask;
    }
    // ... rest of your logic
}

// ITokenValidator implementation
public bool ValidateToken(AuthorizationHandlerContext context, IdentityRequirement<TRole> requirement) {
    // Use context.User or other properties directly here
    ...
}

2. Don't Throw Exceptions in Authorization Handlers #

ASP.NET Core's authorization system is designed to be declarative—handlers should signal failure by calling context.Fail() instead of throwing UnauthorizedException. Throwing exceptions here bypasses the framework's built-in handling (like returning proper 401/403 status codes, integrating with authentication schemes, or supporting policy-based authorization workflows).

Replace this:

//若未满足要求则调用ThrowUnathorizedException()
ThrowUnathorizedException();

With this:

context.Fail();
return Task.CompletedTask;

If you need custom error responses (like a JSON payload instead of a plain 403), add a middleware or action filter that checks the authorization result and transforms the response accordingly—don't handle it in the handler itself.

3. Integrate ITokenValidator Cleanly #

Since you're implementing ITokenValidator alongside AuthorizationHandler, make sure your validation logic doesn't rely on shared state (like the problematic AuthContext property). Pass all necessary data (user claims, requirement details) directly to your validator methods to keep them stateless and thread-safe.

4. Generic TRole Constraint is a Win #

Your where TRole : Role constraint is a smart choice—it enforces type safety, ensuring only your role-derived types can be used with this handler. Just double-check that your IdentityRequirement<TRole> uses the same constraint to avoid mismatched generic types when registering policies.

Registration & Usage Tips #

• Register the Handler Correctly: To avoid singleton issues, register your handler as scoped or transient (not singleton):

  builder.Services.AddScoped<IAuthorizationHandler, IdentityHandler<YourConcreteRole>>();
  

• Define Your Authorization Policy: Link your requirement to a policy in your startup configuration:

  builder.Services.AddAuthorization(options => {
      options.AddPolicy("AdminOnly", policy => 
          policy.Requirements.Add(new IdentityRequirement<AdminRole>()));
  });
  

内容的提问来源于stack exchange，提问作者miechooy