ASP.NET Core自定义鉴权实战：从AuthenticationHandler到授权策略

在C#和后端开发这个圈子里，鉴权（Authentication）和授权（Authorization）一直是“看起来简单，做起来想骂娘”的典型代表。尤其当你接手的是一个内部OA、工控上位机、或者数据中台项目，面对一套完全不能用传统用户名密码去套用的认证逻辑时，你会发现自己被卡在框架的条条框框里，怎么都绕不出去。

我自己就踩过这个坑。当时做一个设备数据采集的上位机服务，要求客户端通过TCP长连接报文里的某个动态字段进行身份校验，同时还要和内部的人员系统打通权限。直接用ASP.NET Core自带的Cookie或JWT方案根本不现实，因为数据不在Header里、Token的签发规则也不一样。最后折腾了一圈，发现最靠谱的方式就是基于ASP.NET Core的认证管道，自己写一套“自定义鉴权”方案。今天这篇文章，就我用过的实战经验，把从设计思路到落地的完整链路拆开讲清楚，适合所有已经跨过入门阶段、想掌握认证底层逻辑的C#开发者。

只需要记住一个核心理念：在ASP.NET Core里，认证和授权是两个分离的管道，自定义鉴权的本质就是往这两条管道里插入自己的处理器。

1. 内容整体设计与思路拆解

1.1 为什么需要自定义鉴权，而不是直接用内置方案

很多新手经常问一个问题：“框架里不是已经有JWT Bearer或者Cookie Authentication了吗？为什么还要自己写一套？”

这个问题问得好。内置方案的适用范围是“标准场景”，什么是标准场景？就是客户端发请求时，在HTTP Header里带上Authorization: Bearer {token}，这个Token是一段符合JWT规范、由IdentityModel库生成的加密字符串。如果你的业务恰好长这样，那直接用内置方案没任何问题。

但现实世界的业务需求往往不走寻常路：

• 你的客户端是PLC或者单片机，HTTP请求报文结构是固定的，根本没法自定义Header。
• 你的Token不是JWT，而是自己用RSA或者国密算法签名的一段数据。
• 你的身份来源是另一个系统的Session ID，需要调用远程接口校验。
• 你的系统要求同一个接口支持多种客户端，不同客户端用完全不同的认证方式，比如上位机用报文摘要，前端Web用Cookie。

遇到这些情况，死磕内置方案就会把自己逼疯。最好的做法是利用ASP.NET Core认证管道的扩展点，实现一个带自定义逻辑的AuthenticationHandler。这样你的鉴权代码既能被框架统一调度，又能完全按照自己的业务规则来执行。

1.2 认证与授权分离，是自定义鉴权的地基

必须在动笔之前搞清楚一个概念：认证和授权到底分别管什么。

**认证（Authentication）**是回答“你是谁”的问题。它负责从请求中提取凭据（可能是Token、Cookie、报文里的某个字段），然后验证这个凭据是否合法，最后把用户信息塞进HttpContext.User。认证失败，请求在这里就会被拦下来，返回401。

**授权（Authorization）**是回答“你能做什么”的问题。它基于认证阶段得到的用户信息，判断当前用户是否具备访问某个接口或资源的权限。授权失败，返回403。

这两个阶段由不同的中间件处理，中间通过HttpContext.User传递数据。所以，你完全可以把认证阶段换成自己的实现，而授权阶段继续用框架的[Authorize]特性，两者互不冲突。

这也正是自定义鉴权的核心设计思路：只替换认证芯片，保留框架原有骨架。这样做的好处很多：你可以继续用[Authorize]标签做接口保护，继续用IClaimsTransformation做Claim的二次加工，还能和内置的授权策略无缝集成。这套思路在实践中非常稳，框架不会因为你换了认证方式就“罢工”。

2. 方案选型：AuthenticationHandler vs 中间件

2.1 先搞清楚两个扩展点的边界

实现自定义鉴权主要有两条路：一是写自定义中间件，直接在管道里处理身份逻辑；二是写自定义AuthenticationHandler，把它挂到认证管道里。我见过不少项目直接用中间件做鉴权，代码写得倒也利索，但后续维护的时候往往会踩坑。

中间件的方式相当于把认证逻辑写死在管道里，比如你写了一个app.Use(async (context, next) => { ... })的中间件，在里面解析Token、验证Token、设置context.User。跑起来确实没问题，但问题在于这个逻辑很难被复用，也很难和框架内的[Authorize]、Policy这些高阶层机制配合。你等于是在框架外面另开了一条赛道。

而AuthenticationHandler是ASP.NET Core认证管道的正规军。它遵循统一的接口契约，被框架调度，能天然支持[Authorize]、Policy、AllowAnonymous这些东西。简单说，你实现了IAuthenticationHandler之后，自定义鉴权就“升级”成了和JWT Bearer、Cookie平级的一等公民。

2.2 为什么更多时候选AuthenticationHandler

我在实际项目里两种方案都试过，如果做快速原型确实中间件更快，但一旦进入正式业务，我强烈建议使用AuthenticationHandler。

原因很简单，接入了认证管道之后，[Authorize]和[AllowAnonymous]才能真正生效。你写一个[Authorize]标签挂在Controller上，框架会调用认证管道里注册的Handler去执行认证逻辑，这套机制不需要你额外写任何判断代码。而如果走中间件，你还需要自己判断每个接口是不是有[AllowAnonymous]，这工作量不是一点半点。

另外，自定义AuthenticationHandler还能用AuthenticationScheme做多方案并存。比如我做过的一个项目，同时对接PC端上位机和Web端后台，两套认证逻辑完全不同，但它们在同一个服务里和平共处。因为AddAuthentication()里可以注册多个Scheme，框架通过不同的Scheme名称路由到各自的Handler。这种灵活性是中间件方案给不了的。

2.3 自定义认证Handler的生命周期与依赖注入

需要特别注意的一个细节：AuthenticationHandler默认注册为单例（Singleton）。这意味着你不能直接把DbContext、IUnitOfWork这类Scoped服务构造函数注入进去，因为生命周期不匹配。

很多第一次写自定义Handler的人在这里栽过跟头，跑起来就报“Cannot resolve scoped service from root provider”之类的错。解决方式不是把DbContext改成单例（那是挖坑），而是在Handler里面通过IServiceScopeFactory现场创建作用域。

csharp复制public class CustomAuthHandler : AuthenticationHandler<CustomAuthOptions>
{
    private readonly IServiceScopeFactory _scopeFactory;

    public CustomAuthHandler(
        IOptionsMonitor<CustomAuthOptions> options,
        ILoggerFactory logger,
        UrlEncoder encoder,
        IServiceScopeFactory scopeFactory) 
        : base(options, logger, encoder)
    {
        _scopeFactory = scopeFactory;
    }

    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        using var scope = _scopeFactory.CreateScope();
        var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        // ... 后续逻辑
    }
}

这个坑我当年踩过，后来想通了：Handler是被框架复用的，每个请求都要用，但它自己又是单例，所以它不能直接持有“请求级”的服务，只能通过作用域工厂去创建。这个模式听上去绕，其实逻辑很顺：框架负责请求级管道的生命周期，Handler负责借用请求级服务。

3. 核心细节解析与实操要点

3.1 从零实现一个自定义鉴权Handler

现在进入正文，我们以“内部上位机系统”为例，实现一个基于“客户端Id+签名”的鉴权方案。这个场景很典型：客户端发起TCP请求，需要把设备Id和动态签名放在请求的某个位置（这里为了方便演示，模拟成HTTP Header），服务端验签通过就认为身份合法。

首先定义认证选项类，继承自AuthenticationSchemeOptions：

csharp复制public class CustomAuthOptions : AuthenticationSchemeOptions
{
    // 如果签名需要额外参数，可以放在这里
    public string SigningKey { get; set; } = string.Empty;
}

然后写核心Handler，继承AuthenticationHandler<CustomAuthOptions>：

csharp复制public class CustomAuthHandler : AuthenticationHandler<CustomAuthOptions>
{
    private readonly IServiceScopeFactory _scopeFactory;

    public CustomAuthHandler(
        IOptionsMonitor<CustomAuthOptions> options,
        ILoggerFactory logger,
        UrlEncoder encoder,
        IServiceScopeFactory scopeFactory) 
        : base(options, logger, encoder)
    {
        _scopeFactory = scopeFactory;
    }

    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        // 取客户端Id
        if (!Request.Headers.TryGetValue("X-Client-Id", out var clientId))
        {
            return AuthenticateResult.NoResult();
        }

        // 取签名
        if (!Request.Headers.TryGetValue("X-Signature", out var signature))
        {
            return AuthenticateResult.NoResult();
        }

        using var scope = _scopeFactory.CreateScope();
        var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();

        // 从数据库查出该客户端对应的密钥
        var client = await dbContext.Clients
            .AsNoTracking()
            .FirstOrDefaultAsync(c => c.ClientId == clientId.ToString());

        if (client == null)
        {
            return AuthenticateResult.Fail("未知的客户端");
        }

        // 这里用简单的SHA256做示例，生产环境建议使用HMAC-SHA256
        var payload = $"{clientId}|{DateTime.UtcNow.Ticks}";
        var computedSignature = ComputeHash(payload, client.SecretKey);

        if (!FixedTimeEquals(computedSignature, signature.ToString()))
        {
            return AuthenticateResult.Fail("签名校验失败");
        }

        // 构造ClaimsPrincipal
        var claims = new[]
        {
            new Claim(ClaimTypes.Name, client.ClientName),
            new Claim("ClientId", client.ClientId.ToString()),
            new Claim(ClaimTypes.Role, client.Role)
        };

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

        return AuthenticateResult.Success(ticket);
    }

    private static string ComputeHash(string input, string key)
    {
        using var hmac = new HMACSHA256(Encoding.UTF8.GetBytes(key));
        var hash = hmac.ComputeHash(Encoding.UTF8.GetBytes(input));
        return Convert.ToBase64String(hash);
    }

    private static bool FixedTimeEquals(string a, string b)
    {
        return CryptographicOperations.FixedTimeEquals(
            Encoding.UTF8.GetBytes(a), Encoding.UTF8.GetBytes(b));
    }
}

这个Handler的逻辑不算复杂，但有几个要点值得展开讲讲：

第一，AuthenticateResult.NoResult()和AuthenticateResult.Fail()是有区别的。NoResult()表示“我不处理这个请求的认证”，如果后面还有其他认证Scheme，框架会往下走；Fail()则直接判定认证失败，返回401。当你做多方案共存时，这个区分非常重要。

第二，FixedTimeEquals是为了防止计时攻击。如果你直接用==比较两个字符串，攻击者可以通过响应时间一点点推测出正确的签名。虽然内网系统不一定有人这么闲，但写成常量时间比较是一个好习惯。

第三，AuthenticationTicket里必须带上Scheme.Name，否则后续的授权策略无法正确识别用户身份来源。

3.2 注册自定义鉴权方案

Handler写好了，接下来需要在Program.cs里把这个方案注册进去。步骤如下：

csharp复制builder.Services.AddAuthentication(options =>
{
    // 默认认证方案
    options.DefaultAuthenticateScheme = "CustomAuth";
    options.DefaultChallengeScheme = "CustomAuth";
})
.AddScheme<CustomAuthOptions, CustomAuthHandler>("CustomAuth", "自定义鉴权方案");

这里有两个容易被忽略的坑：

第一个坑是DefaultChallengeScheme。如果只设置DefaultAuthenticateScheme，匿名用户访问[Authorize]接口时可能会收到奇怪的重定向或者空白页，因为框架不知道拿什么方案去“挑战”用户。设置成同一个自定义方案后，匿名访问就会正确返回401。

第二个坑是AddScheme的泛型参数。第一个泛型是选项类，第二个泛型是Handler类，顺序不能搞反。写错的话，编译期不会报错，但运行时会抛出“InvalidOperationException: No authentication handler is registered for the scheme 'CustomAuth'”之类的提示。

另外，如果你还有JWT之类的其他方案，可以同时注册，通过不同Scheme名称区分。比如：

csharp复制options.DefaultAuthenticateScheme = "CustomAuth";
options.DefaultChallengeScheme = "CustomAuth";
// 同时保留JWT的注册，供其他模块使用

3.3 让自定义方案配合授权策略

认证通过只是第一步。业务里，不同的接口往往还有不同的权限要求。自定义鉴权方案完全可以配合框架内置的授权策略使用。

首先在Program.cs里注册一个策略：

csharp复制builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("OnlyAdmin", policy =>
    {
        policy.RequireRole("Admin");
    });
    options.AddPolicy("ClientOnly", policy =>
    {
        policy.RequireClaim("ClientId");
    });
});

然后在Controller或者Action上使用：

csharp复制[Authorize(AuthenticationSchemes = "CustomAuth", Policy = "ClientOnly")]
[ApiController]
[Route("api/[controller]")]
public class DataController : ControllerBase
{
    [HttpGet]
    public IActionResult Get()
    {
        return Ok("受保护的数据");
    }
}

这里AuthenticationSchemes = "CustomAuth"代表这个接口只认我们自定义的认证方案，Policy则进一步限制必须包含ClientId声明。我通常建议在Controller上显式声明认证方案，不要完全依赖全局默认，特别是在多方案并存的系统里，显式声明让别人看代码的时候一目了然。

4. 实操过程与核心环节实现

4.1 更复杂的场景：多客户端多密钥的签名生成与校验

上面例子里的签名校验有点简化，因为我把时间戳放在了payload里，但这个时间戳并没有真正参与校验逻辑。实际上，一个相对严谨的签名方案应该包含时间戳防重放。

我来分享一个更完整的实操版。客户端请求时，会带上三个信息：

• X-Client-Id: 分配给的客户端Id
• X-Timestamp: 当前Unix时间戳
• X-Signature: Base64(HMAC-SHA256(secretKey, clientId + timestamp))

服务端Handler的校验逻辑修改如下：

csharp复制protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
{
    if (!Request.Headers.TryGetValue("X-Client-Id", out var clientIdValues))
        return AuthenticateResult.NoResult();
    if (!Request.Headers.TryGetValue("X-Timestamp", out var timestampValues))
        return AuthenticateResult.NoResult();
    if (!Request.Headers.TryGetValue("X-Signature", out var signatureValues))
        return AuthenticateResult.NoResult();

    var clientId = clientIdValues.ToString();
    var timestamp = timestampValues.ToString();
    var signature = signatureValues.ToString();

    // 校验时间戳是否在允许的误差范围内（比如5分钟）
    if (!long.TryParse(timestamp, out var ticks))
        return AuthenticateResult.Fail("非法的时间戳");

    var requestTime = DateTimeOffset.FromUnixTimeSeconds(ticks);
    if (DateTimeOffset.UtcNow - requestTime > TimeSpan.FromMinutes(5))
        return AuthenticateResult.Fail("请求已过期");

    using var scope = _scopeFactory.CreateScope();
    var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();

    var client = await dbContext.Clients
        .AsNoTracking()
        .FirstOrDefaultAsync(c => c.ClientId == clientId);

    if (client == null)
        return AuthenticateResult.Fail("未知的客户端");

    var payload = $"{clientId}|{timestamp}";
    var expectedSignature = ComputeSignature(payload, client.SecretKey);

    if (!FixedTimeEquals(expectedSignature, signature))
        return AuthenticateResult.Fail("签名校验失败");

    var claims = new[]
    {
        new Claim(ClaimTypes.Name, client.ClientName),
        new Claim("ClientId", client.ClientId.ToString()),
        new Claim(ClaimTypes.Role, client.Role)
    };

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

    return AuthenticateResult.Success(ticket);
}

校验时间戳的最大意义是防重放攻击。即使攻击者截获了合法的请求报文，只要过了时间窗口，这个请求就无法再次使用。对于工控上位机这种长连接系统来说，这个机制非常有用，能挡住大部分重放攻击。

这里有个细节：时间戳的粒度我用的是Unix秒，如果系统对实时性要求更高，可以改用毫秒级别。但要注意，粒度越细对客户端和服务端的时钟同步要求越高。内网系统一般用分钟级容差就够了，公网系统建议5分钟到15分钟之间做个平衡。

4.2 从数据库动态加载密钥，而不是写死在配置文件里

上面代码里密钥是从Clients表查出来的，这个设计是有意为之。不要把密钥硬编码在appsettings.json里，原因有两点：

一是安全问题。配置文件会进版本库、会被开发人员拉下来看，一旦泄露，所有客户端密钥全部暴露。放数据库里，至少还能通过数据库权限控制访问。

二是运维问题。业务上线后要新增一个客户端，如果密钥在配置文件里，就意味着要改配置、重新发布、重启服务。放数据库里，只需要往表里插一条记录，服务完全不用重启。

我在项目里一般是这么建表的：

sql复制CREATE TABLE Clients (
    Id INT PRIMARY KEY IDENTITY(1,1),
    ClientId NVARCHAR(50) NOT NULL UNIQUE,
    ClientName NVARCHAR(100) NOT NULL,
    SecretKey NVARCHAR(128) NOT NULL,
    Role NVARCHAR(50) NOT NULL DEFAULT 'ClientUser',
    IsActive BIT NOT NULL DEFAULT 1,
    CreatedAt DATETIME2 NOT NULL DEFAULT GETDATE()
);

对应地，写一个简单的实体类，用Dapper或者EF Core访问都行：

csharp复制public class ClientAccount
{
    public int Id { get; set; }
    public string ClientId { get; set; } = string.Empty;
    public string ClientName { get; set; } = string.Empty;
    public string SecretKey { get; set; } = string.Empty;
    public string Role { get; set; } = "ClientUser";
    public bool IsActive { get; set; }
}

4.3 预计算签名减少耗时，提升鉴权性能

自定义鉴权方案如果每次请求都查一次数据库，在高并发场景下其实是个性能瓶颈。数据库查询的延迟一般都在毫秒级，但对于调用频繁的上位机接口来说，累加起来也是不小的开销。

我在线上项目里会做一个简单的字典缓存：

csharp复制public class ClientCache
{
    private readonly IMemoryCache _cache;
    private readonly IServiceScopeFactory _scopeFactory;

    public ClientCache(IMemoryCache cache, IServiceScopeFactory scopeFactory)
    {
        _cache = cache;
        _scopeFactory = scopeFactory;
    }

    public async Task<ClientAccount?> GetClientAsync(string clientId)
    {
        if (_cache.TryGetValue($"client_{clientId}", out ClientAccount? client))
        {
            return client;
        }

        using var scope = _scopeFactory.CreateScope();
        var dbContext = scope.ServiceProvider.GetRequiredService<AppDbContext>();

        client = await dbContext.Clients
            .AsNoTracking()
            .FirstOrDefaultAsync(c => c.ClientId == clientId && c.IsActive);

        if (client != null)
        {
            _cache.Set($"client_{clientId}", client, TimeSpan.FromMinutes(10));
        }

        return client;
    }
}

然后在Handler里注入这个缓存类。需要注意，缓存周期不要设太久，否则客户端密钥轮换后，旧密钥在缓存期内依然有效。10分钟是一个比较合理的折中值。

如果连内存缓存都嫌慢，可以在服务启动时一次性加载所有客户端密钥到静态字典里，然后监听数据库变更事件做更新。不过这种做法会让架构变复杂，除非性能测试确实告警，否则不建议一上来就用这种方案。

5. 常见问题与排查技巧实录

5.1 为什么[AllowAnonymous]失效了

这是自定义鉴权方案里最让人头秃的问题之一。明明在Controller上挂了[AllowAnonymous]，访问接口时还是被拦截了，返回401。

排查方向其实很清晰：AllowAnonymous跳过的是“授权”阶段的拦截，如果你的代码里在认证阶段（也就是Handler里）对一个不需要认证的请求直接返回了AuthenticateResult.Fail()，那[AllowAnonymous]就救不了你。

怎么解决？在返回Fail()之前先判断一下当前请求是否允许匿名。一般情况下可以在Handler外面包一层，或者采用另一种思路：认证阶段尽量返回NoResult而不是Fail。因为没有有效的认证凭据并不代表用户不合法，也许这个接口本来就不需要认证。把Fail留给那些“明显非法携带凭据并且校验不过”的情况。然后，授权阶段自然会拦截需要认证的接口。

这一点在官方文档里写得不明显，全得靠实战经验总结。我见过同事的代码里在Handler里写满了Fail()，结果整个系统的[AllowAnonymous]形同虚设，排查了半天才发现是认证阶段把匿名请求“一刀切”了。

5.2 如何在Handler里读取Body内容

另一个高频问题是：我的签名是根据请求体内容计算的，所以要读Request.Body。但ASP.NET Core的Request.Body是只读向前流，第一次读完之后流位置就到了末尾，后面框架再去读就什么都读不到了。

解决方案是在读之前先启用缓冲：

csharp复制Request.EnableBuffering();
using var reader = new StreamReader(Request.Body, Encoding.UTF8, leaveOpen: true);
var body = await reader.ReadToEndAsync();
Request.Body.Position = 0;

注意EnableBuffering()必须在读取之前调用，而且读取完一定要把流位置归零。leaveOpen: true也很重要，否则流被释放了框架后面没法读。

如果嫌麻烦，也可以采用“在中间件里先读Body，然后存到HttpContext.Items里”的做法。我个人的建议是，签名计算尽量用Header字段，不要依赖请求体，因为请求体读取时机不好控制，容易把管道搞乱。除非业务上实在没办法。

5.3 处理“认证成功但授权失败”时的响应格式

很多人在自定义鉴权方案里会遇到一个恼人的问题：认证失败时，默认返回401页面是空的，客户端（尤其是上位机）拿不到任何有效错误信息。我建议在Program.cs里全局配置一下认证和授权的响应处理。

在.NET 8中，可以这样设置：

csharp复制builder.Services.AddAuthentication(options =>
{
    options.DefaultAuthenticateScheme = "CustomAuth";
    options.DefaultChallengeScheme = "CustomAuth";
})
.AddScheme<CustomAuthOptions, CustomAuthHandler>("CustomAuth", "自定义鉴权方案")
.AddJwtBearer("Jwt", options =>
{
    // JWT方案配置
});

这时候OnChallenge和OnForbidden事件分别对应401和403：

csharp复制builder.Services.AddAuthentication(options => ...)
    .AddScheme<CustomAuthOptions, CustomAuthHandler>("CustomAuth", options => ...)
    .AddJwtBearer("Jwt", options =>
    {
        options.Events = new JwtBearerEvents
        {
            OnChallenge = context =>
            {
                context.HandleResponse();
                context.Response.StatusCode = StatusCodes.Status401Unauthorized;
                return context.Response.WriteAsJsonAsync(new
                {
                    code = 401,
                    message = "未认证或认证已过期"
                });
            },
            OnForbidden = context =>
            {
                context.Response.StatusCode = StatusCodes.Status403Forbidden;
                return context.Response.WriteAsJsonAsync(new
                {
                    code = 403,
                    message = "没有权限访问该资源"
                });
            }
        };
    });

如果你的自定义Handler也想统一JSON格式，可以仿照JWT Bearer的方式，在Handler里捕获认证失败后的逻辑，或者在选项里加一个Events属性。不过更省事的方案是写一个全局异常处理中间件，专门处理认证授权相关的异常状态码，返回统一的JSON结构。这样一来，上位机或者其他客户端解析返回结果时就不用做多种格式兼容了，能省掉不少沟通成本。

5.4 多Scheme共存时如何保证不串门

如果你在一个项目里同时启用多个认证方案（比如Web端用Cookie，上位机IPC用自定义方案，第三方开放接口用JWT），很容易出现“串门”问题：某个本来该走JWT校验的请求，被自定义方案拦截了。

解决方式有两个层面：

第一个层面是在Controller上显式声明：

csharp复制[Authorize(AuthenticationSchemes = "Jwt")]

第二个层面是在全局注册时指定默认方案为“最严格”的那个，其他方案通过显式声明启用的方式使用。我不建议把所有方案都设置为默认方案，这会导致管道顺序混乱，排查问题的时候非常痛苦。

5.5 密钥轮换的平滑过渡

最后聊一个运维层面的问题。系统上线一段时间后，出于安全考虑需要轮换客户端的密钥。如果直接改数据库里的密钥，新旧密钥切换期间，所有已经部署的客户端会集体失效，因为它们还在用旧密钥签名。

平滑的做法是引入双密钥机制：数据库里保留两个密钥字段，CurrentSecretKey和PreviousSecretKey。校验时先拿CurrentSecretKey算一遍，失败再用PreviousSecretKey算一遍。新客户端都使用CurrentSecretKey，旧的客户端在一段时间过渡期内还能用PreviousSecretKey。

csharp复制var isCurrentValid = FixedTimeEquals(
    ComputeSignature(payload, client.CurrentSecretKey), signature);

var isPreviousValid = !isCurrentValid && !string.IsNullOrEmpty(client.PreviousSecretKey) 
    && FixedTimeEquals(
        ComputeSignature(payload, client.PreviousSecretKey), signature);

if (!isCurrentValid && !isPreviousValid)
{
    return AuthenticateResult.Fail("签名校验失败");
}

轮换时，先把PreviousSecretKey更新为当前的CurrentSecretKey，再把CurrentSecretKey设成新值。等过几天确定所有客户端都升级完成后，再清空PreviousSecretKey。这个操作我之前在实际项目里做了几次，明显比“直接停机换密钥”平稳得多，客户端那边几乎无感。

6. 性能优化与安全加固

6.1 减少数据库查询对鉴权性能的影响

自定义鉴权方案的核心瓶颈通常不在签名计算本身，因为SHA256或HMAC-SHA256的计算速度非常快，一次调用大约在微秒级。真正的瓶颈是每次请求都查一次数据库拿密钥。如果这个接口每秒钟被调用几百次，数据库的压力就会明显上来。

内存缓存是我比较推荐的第一步优化手段。将客户端信息缓存在内存里，过期时间设为10到15分钟，可以有效减少数据库的查询压力。如果服务是单实例部署，内存缓存就够了；如果是多实例部署，可以考虑用分布式缓存（比如Redis），不过复杂度和运维成本会明显上升。

另外，尽量使用AsNoTracking()来查询只读数据，EF Core会节省掉变更跟踪的开销。这种微优化在低并发时无感，在压测时能拉开差距。

6.2 日志记录与审计

鉴权模块一定要有完善的日志记录。不是为了出问题后甩锅，而是为了排查问题时有迹可循。我一般在Handler里加上结构化日志：

csharp复制Logger.LogInformation("客户端 {ClientId} 鉴权成功，来自 {RemoteIp}", clientId, Context.Connection.RemoteIpAddress);

Logger.LogWarning("客户端 {ClientId} 签名校验失败，签名 {Signature}，来自 {RemoteIp}", clientId, signature, Context.Connection.RemoteIpAddress);

这里有个细节：不要记录完整的签名值或者密钥，万一日志系统被拖库，这些敏感信息就会泄露。我一般只记录签名前几位（比如前8位）和时间戳，足够排查问题，又不会泄露核心凭据。

6.3 HTTPS与传输安全

自定义鉴权方案再完善，如果数据在网络上明文传输，一切都是白搭。签名可能会被中间人截获并重放。虽然不是所有内网环境都适合部署HTTPS（尤其是和PLC、单片机通信的场景），但我强烈建议在条件允许的前提下，为API入口加上HTTPS或者至少做网络隔离。

有一个折中方案是：传输层用自定义的加密协议包一层，应用层继续走我们的鉴权方案。很多上位机通信框架本身就支持TLS隧道，如果客户端支持，优先把TLS用起来，这样双保险会舒服很多。

我个人在实际操作中的体会是，自定义鉴权这件事，真正难的不是写代码，而是把方案放在整个系统架构的合适位置。你是要替换认证，还是连授权一起替换？你是要和框架深度集成，还是要在框架旁边搭一套独立逻辑？这些想清楚了，写代码只是时间问题。如果你正准备改造手头的老系统，或者要给新项目定制认证逻辑，我建议先画一张当前请求管道从进入服务到返回响应的完整时序图，标出认证和授权分别在哪一层、谁先谁后、哪些环节要换，再照着上面这套Handler思路去填代码，会比直接上手写流畅很多。