IDX10500异常排查：Service1验证Microsoft Entra ID令牌失败

问题背景 #

• 我们有两个Entra ID租户A和B：Service1部署在租户A，配置接受颁发者为https://login.microsoftonline.com/A/v2.0的Bearer令牌；Service2配置接受租户B颁发者https://login.microsoftonline.com/B/v2.0的令牌
• 此前运行正常，周日Service1突然触发IDX10500: Signature validation failed. No security keys were provided to validate the signature.错误，Service2无异常
• 检查租户A的OIDC发现文档https://login.microsoftonline.com/A/v2.0/.well-known/openid-configuration，确认令牌头部的密钥ID存在于对应的jwks_urihttps://login.microsoftonline.com/A/discovery/v2.0/keys中
• 发现该密钥ID也完整存在于租户B的jwks_uri中，将Service1的JwtBearerOptions.MetadataAddress改为租户B的发现文档地址后，签名验证功能恢复正常

可能的原因分析 #

1. 缓存失效/异常：
   .NET的JWT中间件默认会缓存OIDC元数据和JWKS密钥，缓存过期前不会主动刷新。如果租户A的JWKS端点在Service1缓存刷新时段出现临时故障（比如CDN节点返回不完整数据），就会导致本地缓存的密钥集合缺失目标kid，触发验证失败。而租户B的JWKS一直正常，切换后中间件拉取到完整密钥，验证通过。

2. Entra ID租户A的临时服务故障：
   微软Entra ID的租户级JWKS服务可能出现区域性或租户特定的同步延迟、分发异常，故障发生时Service1请求租户A的JWKS无法获取到目标密钥，事后检查时服务已恢复，所以密钥显示存在。

3. JWKS格式兼容性问题：
   虽然两个租户的密钥参数一致，但租户A返回的JWKS可能存在格式细节差异（比如字段大小写、非标准附加字段），导致.NET密钥解析器无法识别，而租户B的返回格式完全兼容。

处理建议 #

1. 恢复原配置验证：
   把Service1的MetadataAddress改回租户A的地址，同时重启服务（或配置较短的缓存过期时间），观察是否还会报错。如果恢复正常，基本可以确定是临时缓存或服务异常导致。

2. 调整缓存策略：
   检查当前使用的.NET版本和JWT中间件缓存设置，通过JwtBearerOptions.ConfigurationManager配置合理的元数据/JWKS刷新间隔，避免长期依赖过期缓存，降低类似问题的发生概率。

3. 上报微软支持：
   如果恢复原配置后问题复现，或者能确认故障时段租户A的JWKS端点存在异常响应，建议通过微软365管理员中心提交支持工单，提供以下信息：

   • 故障发生的UTC时间范围
   • Service1对应的租户ID、应用ID
   • 故障令牌的kid值
   • 租户A和B的JWKS响应对比内容
     微软可以通过后台日志排查租户A的JWKS服务是否存在底层异常。

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