.NET 5下ServiceStack对接Azure AD B2C携带Bearer令牌仍401的排查

之前你在AppHost初始化文件里打不到断点，是因为401的触发逻辑全部在请求处理管线里运行，和应用启动阶段的初始化代码没有关系，需要把断点打在以下位置才能完整捕获执行流：

• 打在JwtAuthProviderReader类的AuthenticateAsync方法第一行：这里是所有带Bearer令牌请求进入JWT校验逻辑的统一入口，只要断点命中，就能顺着代码往下看是哪一步校验不通过被判定为未授权。
• 打在IsValidJwt方法的所有分支校验点：这里会依次校验令牌签名、过期时间、发行方、受众、令牌版本，只要某一步校验返回false，就会直接抛出401。
• 打在AuthenticateAttribute类的ExecuteAsync方法内部：这里是ServiceStack授权校验的总入口，会明确捕获到未授权的具体触发场景——是没有匹配到认证provider、会话为空还是权限不匹配。
• 打在你自定义的PopulateSessionFilter委托内部：确认B2C返回的令牌负载能不能正常映射到AuthUserSession字段，有没有因为字段映射缺失导致会话被判定为无效。

• 优先核对JWT配置的受众（Audience）和实际令牌的匹配度：从Postman拿到的B2C访问令牌，其负载中的aud声明必须和你JWT Provider配置的Audience值完全一致。很多从普通Azure AD迁移到B2C的场景，会沿用旧的Audience配置，和B2C应用注册的实际应用ID不匹配，直接被JWT校验环节拦截返回401。
• 核对发行方（Issuer）配置的匹配度：Azure AD B2C的令牌发行方是带租户域名和用户流策略ID的动态值，和普通Azure AD的固定Issuer格式完全不同，如果配置里的Issuer没有完整匹配令牌中iss、tfp声明的值，会直接校验失败返回401。
• 排查Swagger正常、Postman异常的本质差异：Swagger走的OAuth授权流程拿到的令牌，其作用域、受众和你Postman手动获取的令牌参数往往存在差异——常见的差异是Swagger交互时用的Scope包含了openid、profile，而Postman手动拼接的授权URL漏配了对应的scope，导致拿到的令牌不是用来调用API的访问令牌，而是ID令牌，也会被校验拦截。
• 检查路由移除操作的影响：你代码中执行了auth.ServiceRoutes.Remove(typeof(AuthenticateService))操作，部分ServiceStack版本中，该操作会连带移除Bearer令牌请求的校验管线绑定，导致所有带Bearer头的请求无法匹配到对应的认证逻辑，直接返回401。

• 打开调试模式（DebugMode）：ServiceStack的JWT Provider在调试模式下，会在401响应头中直接返回详细的校验失败原因，不需要逐行打断点就能快速定位问题。
• 核对请求头格式：确认Postman中的Authorization头严格遵循Bearer <token>格式，没有多余空格、拼写错误，也没有将令牌放在其他自定义请求头中。

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