ASP.NET Core 5 Web API 如何同时支持Windows认证与OpenID认证？

1. 认证服务的基础默认规则未显式配置 #

你当前使用无参形式调用services.AddAuthentication()，未指定全局的默认认证、挑战方案：

• ASP.NET Core 认证中间件不会自动遍历所有已注册的Scheme去尝试解析用户身份，必须显式指定全局路由规则
• 你在授权策略中罗列的两个Scheme列表，仅在授权执行阶段会被依次触发认证逻辑，但全局认证管道没有打通两个Scheme的自动匹配能力
• 未认证请求触发响应时，没有统一的401状态码返回规则，容易出现302跳转这类完全不符合API预期的行为

2. 场景与认证方案选型完全错位 #

AddOpenIdConnect是为交互式Web应用作为OIDC客户端、走浏览器登录流程设计的，默认实现逻辑和你当前场景完全不匹配：

• 未认证时自动返回302状态码，引导用户跳转到认证服务器的浏览器登录页
• 仅从本地Cookie中读取OIDC流程签发的登录身份，不会主动从请求头的Authorization: Bearer xxx字段提取、校验访问令牌
  这种实现完全不符合"WinForms应用直接携带访问令牌调用API"的场景，是配置失效的核心原因。针对API接收OIDC颁发的访问令牌的场景，应当使用AddJwtBearer作为令牌校验的实现，它的Handler专门负责从请求头提取、校验Bearer类型令牌。

3. 令牌校验参数逻辑存在硬伤 #

你当前在OIDC配置中硬编码SymmetricSecurityKey作为签名校验密钥：

• 主流OpenID Connect认证服务器默认使用非对称算法（RS256/ES256）签发令牌，签名公钥会在认证服务器的公开配置端点自动暴露，不需要手动编写对称密钥
• 硬编码对称密钥会覆盖JWT/OIDC配置的自动元数据发现能力，导致签名校验逻辑和实际认证服务器的规则完全不匹配，所有令牌校验都会直接失败
• 正确的配置应当仅保留Issuer、Audience这类基础校验规则，签名密钥由组件自动从Authority指定的地址拉取公开签名集合。

4. 多方案的协同逻辑未真正打通 #

你在授权策略中指定了Negotiate和OIDC两个Scheme作为认证来源，但因为上述实现选型的错位，实际执行流程为：

• Windows域账号类请求，Negotiate Scheme可正常解析身份
• 携带OIDC令牌的请求，Negotiate Scheme因为没有对应的NTLM/Kerberos凭据直接返回未认证，轮到OIDC Scheme处理时，又因为它的默认逻辑根本不读取请求头的Bearer令牌，同样返回未认证，最终两类请求都可能通不过授权校验。

可正常运行的参考配置 #

// 服务注册阶段
services.AddAuthentication(options =>
{
    // 指定合并认证方案为全局默认入口
    options.DefaultScheme = "CombinedAuth";
    options.DefaultChallengeScheme = "CombinedAuth";
})
// 注册Windows Negotiate域认证方案
.AddNegotiate(IISDefaults.AuthenticationScheme)
// 注册JwtBearer方案处理OIDC颁发的访问令牌
.AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>
{
    options.Authority = Configuration["Issuer"];
    options.Audience = Configuration["Audience"];
    options.TokenValidationParameters = new TokenValidationParameters
    {
        ValidateIssuer = true,
        ValidateAudience = true,
        ValidateLifetime = true,
        ValidateIssuerSigningKey = true
    };
    // 强制未认证时返回401，不触发页面跳转
    options.Events = new JwtBearerEvents
    {
        OnChallenge = context =>
        {
            context.HandleResponse();
            context.Response.StatusCode = StatusCodes.Status401Unauthorized;
            return Task.CompletedTask;
        }
    };
})
// 配置路由型合并认证方案，根据请求特征自动选择对应认证逻辑
.AddPolicyScheme("CombinedAuth", "多方案路由认证", options =>
{
    options.DefaultPolicySelector = context =>
    {
        // 请求携带Bearer令牌时走JwtBearer流程，否则走Windows域认证流程
        if (context.Request.Headers.ContainsKey("Authorization") 
            && context.Request.Headers.Authorization.ToString().StartsWith("Bearer "))
        {
            return JwtBearerDefaults.AuthenticationScheme;
        }
        return IISDefaults.AuthenticationScheme;
    };
});

services.AddAuthorization(options =>
{
    var builder = new AuthorizationPolicyBuilder();
    builder.RequireAuthenticatedUser();
    options.DefaultPolicy = builder.Build();
});

注意：该配置保留了你原有管道配置app.UseAuthentication()、app.UseAuthorization()的顺序，不需要调整管道位置即可生效；同时要确保IIS服务器层面同时开启Windows认证、匿名认证，和原有运行环境保持一致。

内容的提问来源于stack exchange，提问作者Ivan-Mark Debono