ASP.NET Core 2.0 Web API自定义非JWT令牌（GUID）验证最佳实践咨询

针对你提出的两个问题，我来分享一下ASP.NET Core框架推荐的最佳实践——直接重写AuthorizeAttribute.OnAuthorization其实并不是最优选择，框架提供了更贴合设计理念的模块化方案来处理自定义令牌的验证，下面一步步来拆解：

一、核心思路：用自定义AuthenticationHandler处理令牌认证 #

ASP.NET Core的认证系统是基于"方案"（Scheme）设计的，我们可以通过实现AuthenticationHandler来创建专属的GUID令牌认证方案，这比直接修改AuthorizeAttribute更符合职责分离原则，也更容易维护和扩展。

1. 定义认证方案的配置选项 #

首先创建一个类来存储认证方案的配置参数，比如令牌在请求中的传递方式：

public class GuidTokenAuthenticationOptions : AuthenticationSchemeOptions
{
    // 配置令牌对应的请求头名称，默认用X-Token
    public string TokenHeaderName { get; set; } = "X-Token";
}

2. 实现自定义AuthenticationHandler（核心验证逻辑） #

这是验证令牌的核心类，负责从请求中提取令牌、与数据库校验有效性，并生成认证票据：

public class GuidTokenAuthenticationHandler : AuthenticationHandler<GuidTokenAuthenticationOptions>
{
    // 注入自定义的令牌验证服务，用来和数据库交互
    private readonly ITokenService _tokenService;

    public GuidTokenAuthenticationHandler(
        IOptionsMonitor<GuidTokenAuthenticationOptions> options,
        ILoggerFactory logger,
        UrlEncoder encoder,
        ISystemClock clock,
        ITokenService tokenService)
        : base(options, logger, encoder, clock)
    {
        _tokenService = tokenService;
    }

    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        // 步骤1：从请求头中获取令牌
        if (!Request.Headers.TryGetValue(Options.TokenHeaderName, out var tokenHeader))
        {
            // 没有令牌，返回无结果，后续框架会自动返回401
            return AuthenticateResult.NoResult();
        }

        var token = tokenHeader.FirstOrDefault();
        if (string.IsNullOrEmpty(token) || !Guid.TryParse(token, out var guidToken))
        {
            return AuthenticateResult.Fail("无效的令牌格式");
        }

        // 步骤2：调用服务验证令牌是否在数据库中有效（未过期、未被撤销）
        var isValidToken = await _tokenService.ValidateTokenAsync(guidToken);
        if (!isValidToken)
        {
            return AuthenticateResult.Fail("令牌无效或已过期");
        }

        // 步骤3：验证通过，生成用户身份票据
        var claims = new[]
        {
            new Claim(ClaimTypes.NameIdentifier, guidToken.ToString()),
            // 可以添加其他用户相关的Claim，比如用户名、角色等
        };

        var identity = new ClaimsIdentity(claims, Scheme.Name);
        var principal = new ClaimsPrincipal(identity);
        var ticket = new AuthenticationTicket(principal, Scheme.Name);

        return AuthenticateResult.Success(ticket);
    }
}

3. 在Startup中注册认证方案 #

把自定义的认证方案添加到服务管道中，并设置为默认认证/挑战方案：

public void ConfigureServices(IServiceCollection services)
{
    // 注册令牌验证服务（实现验证数据库中令牌有效性的逻辑）
    services.AddScoped<ITokenService, TokenService>();

    // 添加自定义GUID令牌认证方案
    services.AddAuthentication(options =>
    {
        options.DefaultAuthenticateScheme = "GuidToken";
        options.DefaultChallengeScheme = "GuidToken";
    })
    .AddScheme<GuidTokenAuthenticationOptions, GuidTokenAuthenticationHandler>("GuidToken", options =>
    {
        options.TokenHeaderName = "X-Token"; // 可根据实际需求修改请求头名称
    });

    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_0);
}

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    // 注意：一定要在UseMvc之前调用UseAuthentication，确保认证逻辑先执行
    app.UseAuthentication();

    app.UseMvc();
}

二、为什么不推荐重写AuthorizeAttribute.OnAuthorization？ #

AuthorizeAttribute的核心职责是声明授权规则（比如指定允许的角色、策略），而不是处理令牌验证这类认证逻辑。把认证逻辑塞进OnAuthorization会混淆"认证"和"授权"的职责，而且：

• 无法很好地集成到ASP.NET Core的认证管道中，异步处理、错误处理都不够规范
• 代码耦合度高，后续扩展其他认证方式会很麻烦
• 不符合框架的设计理念，维护成本更高

补充：令牌生成与数据库存储的注意事项 #

当用户登录生成GUID令牌时，建议在数据库中存储这些信息：

• GUID令牌本身
• 关联的用户ID
• 令牌过期时间
• 令牌状态（是否被撤销）
  ITokenService.ValidateTokenAsync方法就负责检查这些信息，确保令牌是有效的、未过期且未被用户主动注销的。

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