.NET Core 3.1身份认证问题：默认配置可控性不足且不符合预期

我来帮你一步步拆解并解决这两个核心问题：阻止Identity对API请求的自动重定向，以及让JWT的认证事件回调正常工作，同时最大化利用.NET内置的认证工具，不用自己从零写验证逻辑。

一、修复Identity的API请求重定向问题 #

你已经尝试通过OnRedirectToLogin事件拦截重定向，但代码里有两个细节问题导致它没正确生效：

1. 直接使用未定义的response变量，应该从context中获取context.Response
2. 没有确保响应流程被终止，后续中间件可能仍会触发重定向

修改Piranha的Identity配置中的OnRedirectToLogin回调：

cookieOptions.Events.OnRedirectToLogin = context =>
{
    // 用StartsWithSegments更精准匹配/api开头的路径，避免误匹配类似/api123的路径
    if (context.Request.Path.StartsWithSegments("/api"))
    {
        // 设置401状态码并返回自定义响应
        context.Response.StatusCode = StatusCodes.Status401Unauthorized;
        // 写入响应并终止后续流程
        return context.Response.WriteAsync("Unauthorized.");
    }
    // 非API请求走默认的登录页重定向逻辑
    return defaultAction(context);
};

注意：要确保代码文件引用了Microsoft.AspNetCore.Http命名空间，否则WriteAsync扩展方法会找不到。

二、让JWT的事件回调生效并控制响应 #

你的JWT配置有两个关键问题需要修正：

1. 修复AddApplicationJwt方法的返回值 #

方法最后return;会导致配置无法正确链式生效，应该返回传入的builder对象：

public static AuthenticationBuilder AddApplicationJwt(this AuthenticationBuilder builder, IConfiguration config)
{
    builder.AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
    {
        var issuer = config["Jwt:Issuer"];
        var key = config["Jwt:Key"];
        options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters()
        {
            ValidateIssuer = true,
            ValidateAudience = true,
            ValidateLifetime = true,
            ValidateIssuerSigningKey = true,
            ValidIssuer = issuer,
            ValidAudience = issuer,
            IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(key))
        };

        options.Events = new JwtBearerEvents()
        {
            // 仅在JWT令牌验证抛出异常时触发（比如令牌过期、签名无效）
            OnAuthenticationFailed = context =>
            {
                context.Response.StatusCode = StatusCodes.Status401Unauthorized;
                return context.Response.WriteAsync($"Authentication failed: {context.Exception.Message}");
            },
            // 当未携带令牌或令牌无效触发挑战时，拦截默认重定向
            OnChallenge = context =>
            {
                // 阻止后续中间件的默认重定向逻辑
                context.HandleResponse();
                context.Response.StatusCode = StatusCodes.Status401Unauthorized;
                return context.Response.WriteAsync("Unauthorized: No valid JWT token provided.");
            }
        };
    });
    // 必须返回builder才能让配置链式生效
    return builder;
}

2. 为什么OnAuthenticationFailed没触发？ #

OnAuthenticationFailed只有在JWT令牌验证过程中抛出异常时才会触发（比如令牌过期、签名不匹配）。如果是请求未携带令牌的情况，会触发OnChallenge事件，而不是OnAuthenticationFailed。你之前遇到的JWT场景下的重定向，就是因为默认的Challenge流程会 fallback 到Cookie认证的重定向逻辑，所以必须通过OnChallenge事件拦截并自定义响应。

三、调整中间件顺序（重中之重） #

你的中间件顺序完全错误，这会导致认证、授权、CORS的逻辑混乱失效。正确的顺序应该是：

// 1. 先配置CORS，必须在认证之前，否则CORS头无法正确添加
app.UseCors(x => x
    .AllowAnyMethod()
    .AllowAnyHeader()
    .SetIsOriginAllowed(origin => true) // 生产环境记得替换成具体允许的域名
    .AllowCredentials());

// 2. 认证中间件必须在授权之前，否则授权逻辑无法获取认证信息
app.UseAuthentication();

// 3. 授权中间件
app.UseAuthorization();

// 4. 最后添加Piranha的中间件
app.UsePiranha(options =>
{
    options.UseTinyMCE();
    options.UseIdentity();
    options.UseManager();
});

四、额外优化建议 #

1. 区分API和Web端的认证方案：
   对于API控制器，确保标记[Authorize(AuthenticationSchemes = JwtBearerDefaults.AuthenticationScheme)]，而Piranha的管理器页面会自动使用Cookie认证（你在Piranha配置中已经设置了对应的Cookie选项）。

2. 全局默认认证方案（可选）：
   如果大部分API都用JWT，可以在服务配置时设置默认认证方案，避免每个控制器重复写AuthenticationSchemes参数：

   services.AddAuthentication(options =>
   {
       options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
       options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
   })
   .AddApplicationJwt(Configuration)
   // 保留Piranha的Identity Cookie配置
   .AddCookie(...);
   

3. 统一API响应格式：
   可以把401响应改成JSON格式，更符合API规范：

   return context.Response.WriteAsJsonAsync(new { StatusCode = 401, Message = "Unauthorized" });
   

   记得引用Microsoft.AspNetCore.Http.Json命名空间。

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