AcquireTokenSilentAsync 报failed_to_acquire_token_silently排查

• 缓存读写时序错位：默认Azure AD集成的ITokenCacheFactory采用Cookie序列化存储缓存的机制。你在OnAuthorizationCodeReceived事件中通过授权码换得token、写入缓存的操作，发生在OIDC中间件将最新身份信息加密写入客户端Cookie之前；当用户登录后短时间内（和你日志里登录后7秒就发请求的时间差完全吻合）发起API调用时，客户端携带的Cookie还是旧值，根本读不到刚写入的缓存条目，直接触发Silent获取失败。
• 缓存覆盖的资源不完整：你在授权码兑换阶段，仅拉取了Power BI资源对应的token并写入缓存，从来没有针对Graph API资源完成过授权码换token的操作，当Silent方法尝试找Graph API的token缓存时，自然找不到对应条目，这类请求的失败概率会随Graph API调用占比升高而变大。
• 兜底逻辑完全不适配Web后端场景：你在catch到Silent异常后调用的AcquireTokenAsync搭配无参PlatformParameters，是桌面/移动端场景下弹出交互窗口让用户登录的实现，Web后端没有客户端UI交互能力，走到这个分支必然抛异常，完全起不到兜底作用。
• 多实例部署的缓存隔离问题：如果应用在Azure上开启了多实例负载均衡，默认的缓存实现仅绑定单请求或单实例内存，用户第一次登录的请求落在实例A上写入的缓存，在后续Silent请求被路由到没有缓存的实例B时，就会随机触发获取失败，流量越分散故障概率越高。
• 用户标识匹配偏差：你在Silent获取时传入的UserIdentifier是用户ObjectId，和缓存条目里存储的标识字段没有做严格对齐，部分场景下会出现标识匹配不上，即使缓存里有有效token也命中失败的情况。

• 修正缓存写入时序：在OnAuthorizationCodeReceived事件中，完成token缓存写入后，手动将序列化后的缓存值追加到当前待回写的认证Cookie中，确保客户端拿到的Cookie已经包含刚写入的refresh token值，不要依赖默认OIDC中间件的自动序列化流程。
• 补全授权码阶段的资源兑换逻辑：如果需要同时调用Power BI API和Graph API，在授权码阶段就针对两个目标资源分别完成token兑换，把两个资源对应的refresh token都写入缓存，不要等Silent获取时临时找缺失的缓存条目。
• 替换失效的Web端兜底逻辑：把现有catch分支里的桌面端交互获取方法，改成Silent失败时直接302重定向到Azure AD授权端点，携带两个目标资源的scope参数，让用户重新走一遍授权码流程拉取最新的有效refresh token，禁止在Web后端调用需要用户交互的token获取方法。
• 适配Azure多实例的缓存架构：将默认的内存/Cookie绑定的Token缓存，替换为基于分布式缓存的Token缓存实现，让所有应用实例共享同一份token缓存数据，避免负载均衡导致的实例间缓存不互通的随机故障。
• 统一用户标识匹配规则：将Silent获取时传入的UserIdentifier从ObjectId改为用户的UPI标识，和缓存条目内的存储字段严格对齐，避免标识不匹配导致的缓存命中失败。

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