自定义授权属性与基于策略的授权处理程序选型咨询：API密钥验证场景

Great question—this is a common choice when building API authorization in ASP.NET Core, and the answer depends on your long-term needs and how you want to structure your code. Let’s break down both options:

Custom Authorize Attribute #

• Pros: Quick to implement for simple, one-off scenarios. You can directly inherit from AuthorizeAttribute and override the authorization logic in a single class. For a straightforward API key check, this feels like a "direct" solution.
• Cons: Major drawbacks start showing when you need dependencies (like your database context). Since attributes are instantiated by the CLR, injecting services (via constructor injection) isn’t straightforward—you’ll have to use HttpContext.RequestServices to pull in dependencies, which makes the code less clean and harder to test. It’s also less flexible: if you later want to combine this API key check with other authorization rules (like role checks), you’ll end up with messy, tightly coupled code.

Example of a custom attribute (note the awkward dependency retrieval):

public class ApiKeyAuthorizeAttribute : AuthorizeAttribute
{
    protected override bool AuthorizeCore(HttpContextBase httpContext)
    {
        var dbContext = httpContext.RequestServices.GetService<YourDbContext>();
        if (dbContext == null) return false;

        if (!httpContext.Request.Headers.TryGetValue("apikey", out var apiKeyValues))
            return false;

        var apiKey = apiKeyValues.FirstOrDefault();
        return !string.IsNullOrEmpty(apiKey) && 
               dbContext.ApiKeys.Any(k => k.Key == apiKey && k.IsActive);
    }
}

Policy-Based Authorization Handler #

• Pros: This is the recommended approach in ASP.NET Core for most authorization scenarios, especially when you need dependencies or want scalable, maintainable code. It fits neatly into the framework’s authorization pipeline, supports constructor injection (so you can easily inject your DbContext), and is highly extensible. You can combine multiple requirements into a single policy, write unit tests for the handler easily, and even reuse the logic across different parts of your app.
• Cons: It requires a bit more setup upfront (defining a requirement, handler, and registering the policy), but this extra work pays off in flexibility and maintainability.

Here’s how you’d implement it for your API key scenario:

1. Define an authorization requirement (a marker class for your rule):

public class ApiKeyRequirement : IAuthorizationRequirement
{
    // Add configuration properties here if needed (e.g., allowed key prefixes)
}

2. Create the handler that enforces the requirement:

public class ApiKeyAuthorizationHandler : AuthorizationHandler<ApiKeyRequirement>
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    private readonly YourDbContext _dbContext;

    // Constructor injection works seamlessly here
    public ApiKeyAuthorizationHandler(IHttpContextAccessor httpContextAccessor, YourDbContext dbContext)
    {
        _httpContextAccessor = httpContextAccessor;
        _dbContext = dbContext;
    }

    protected override async Task HandleRequirementAsync(AuthorizationHandlerContext context, ApiKeyRequirement requirement)
    {
        var httpContext = _httpContextAccessor.HttpContext;
        if (httpContext == null)
        {
            context.Fail();
            return;
        }

        // Check for the API key header
        if (!httpContext.Request.Headers.TryGetValue("apikey", out var apiKeyValues))
        {
            context.Fail();
            return;
        }

        var apiKey = apiKeyValues.FirstOrDefault();
        if (string.IsNullOrEmpty(apiKey))
        {
            context.Fail();
            return;
        }

        // Validate against the database
        var isValidKey = await _dbContext.ApiKeys.AnyAsync(k => k.Key == apiKey && k.IsActive);
        if (isValidKey)
        {
            context.Succeed(requirement);
        }
        else
        {
            context.Fail();
        }
    }
}

3. Register the policy and handler in your startup/program code:

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("ValidateApiKey", policy =>
        policy.Requirements.Add(new ApiKeyRequirement()));
});

builder.Services.AddScoped<IAuthorizationHandler, ApiKeyAuthorizationHandler>();
builder.Services.AddHttpContextAccessor(); // Required for accessing HttpContext in the handler

4. Apply the policy to your controllers/actions:

[Authorize(Policy = "ValidateApiKey")]
[ApiController]
[Route("api/[controller]")]
public class SecureController : ControllerBase
{
    // Your endpoints here
}

Final Recommendation #

Go with the policy-based authorization handler. Even if your current scenario seems simple, the ability to inject dependencies cleanly, test your authorization logic easily, and extend the policy later (e.g., adding expiration checks for API keys) makes it the better long-term choice. The custom attribute approach might feel quicker initially, but it leads to technical debt as your app grows.

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