FastEndpoints项目中的JWT认证与ASP.NET Identity共存问题解析

在基于FastEndpoints框架的.NET 8项目中，开发者常会遇到认证方案冲突的问题。本文将以一个典型的"change-password"端点404错误案例为切入点，深入分析JWT认证与ASP.NET Identity共存时的技术细节。

问题现象

开发者在实现密码修改功能时，发现未携带JWT令牌的请求返回了404状态码，而非预期的401未授权响应。核心代码如下：

public class ChangePasswordEndpoint : Endpoint<ChangePasswordRequest>
{
    public override void Configure()
    {
        Post("/auth/change-password");
        Claims("UserId"); // 要求认证
    }
}

根本原因分析

当项目同时配置了两种认证方案时：

1. 首先注册了JWT Bearer认证
2. 随后添加了ASP.NET Identity（默认使用Cookie认证）

此时系统会将最后注册的认证方案（Cookie）作为默认方案。当请求到达时：

1. Cookie认证中间件会主动拦截未认证的请求
2. 默认行为是将请求重定向到登录页（返回404）
3. 这与API接口的预期行为不符

解决方案

方案一：指定端点认证方案

在端点配置中明确指定只使用JWT认证：

public override void Configure()
{
    Post("/auth/change-password");
    AuthSchemes(JwtBearerDefaults.AuthenticationScheme);
    Claims("UserId");
}

方案二：调整认证中间件顺序

确保JWT认证中间件优先处理：

app.UseAuthentication()
   .UseAuthorization();

方案三：禁用Cookie认证的重定向

在服务配置中修改Cookie认证选项：

services.ConfigureApplicationCookie(options => 
{
    options.Events.OnRedirectToLogin = ctx =>
    {
        ctx.Response.StatusCode = 401;
        return Task.CompletedTask;
    };
});

最佳实践建议

1. 对于纯API项目，建议仅使用JWT认证方案
2. 混合应用（API+页面）应明确区分端点认证方案
3. 始终测试未认证情况下的端点响应
4. 考虑使用[AllowAnonymous]特性标记无需认证的端点

通过正确配置认证方案，开发者可以确保API端点返回符合REST规范的响应代码，提升接口的规范性和安全性。