ASP.NET Core与React SPA间SignalR身份认证失败问题排查

架构老林

2026-8-29

根本原因

核心矛盾来自浏览器API限制和默认认证配置的不匹配，和MSAL配置、token有效性无关：

浏览器原生WebSocket构造函数不支持自定义请求头，SignalR在使用WebSocket、Server-Sent Events传输模式时，会自动把accessTokenFactory返回的凭证拼接到连接URL的access_token查询参数中传递，不会放在标准的Authorization请求头里
你当前ASP.NET Core侧的JWT Bearer认证默认仅从Authorization请求头读取token，没有处理查询字符串传递的凭证，因此WebSocket握手阶段服务端拿不到有效身份信息，直接判定为匿名用户，触发DenyAnonymousAuthorizationRequirement授权失败
LongPolling传输基于常规的XHR/fetch请求，支持自定义请求头，可以正常把token放到Authorization头中传递，因此可以完成认证，和你观察到的回退现象完全吻合

修复步骤

调整ASP.NET Core JWT Bearer认证配置，仅针对SignalR Hub端点增加查询字符串token读取逻辑，避免全局开启带来的日志泄露token风险，参考配置代码：

// Program.cs 服务注册部分
builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddMicrosoftIdentityWebApi(builder.Configuration.GetSection("AzureAd"))
    .AddJwtBearer(options =>
    {
        options.Events = new JwtBearerEvents
        {
            OnMessageReceived = context =>
            {
                // 只处理你的Hub路由路径，替换为你实际配置的Hub地址
                if (context.HttpContext.Request.Path.StartsWithSegments("/hub"))
                {
                    // 从查询字符串中取出access_token赋值给认证上下文
                    var token = context.Request.Query["access_token"].FirstOrDefault();
                    if (!string.IsNullOrEmpty(token))
                    {
                        context.Token = token;
                    }
                }
                return Task.CompletedTask;
            }
        };
    });

校验中间件顺序，确保WebSocket中间件在认证、授权中间件之前执行，错误的顺序会导致WebSocket请求无法被正确识别，参考正确顺序：

// Program.cs 中间件管道部分
app.UseRouting();
// WebSocket中间件必须放在认证、授权之前
app.UseWebSockets();
app.UseAuthentication();
app.UseAuthorization();

// 端点映射
app.MapControllers();
app.MapHub<YourCustomHub>("/hub"); // 替换为你的实际Hub类和路由

如果你部署在反向代理（Nginx、IIS、云服务商负载均衡等）之后，需要确认反向代理已开启WebSocket协议支持，转发请求时保留Upgrade、Connection头，同时不要丢弃URL查询字符串中的access_token参数

补充排查点

打开浏览器开发者工具，在网络面板找到WebSocket握手请求（状态码101 Switching Protocols的那条），确认URL中携带的access_token参数值和你MSAL获取到的token完全一致
开启服务端认证中间件的Trace级日志，确认WebSocket请求到达时，OnMessageReceived事件是否正常触发、token是否成功读取、后续的token签名、受众校验是否通过
确认你MSAL申请token时使用的scope是后端API自己暴露的访问权限范围，不是Microsoft Graph等其他服务的scope，避免token受众不匹配导致校验失败

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