Azure App Service Easy Auth中id_token刷新及使用问题咨询

问题1：为何id_token可用于访问下游API？ #

你提到的场景是下游API和当前Web App使用同一个Azure AD应用注册，结合OAuth 2.0隐式流的特性，Azure Easy Auth做了兼容处理：

• 按照OAuth规范，id_token的核心作用是身份验证（确认用户身份信息），access_token才是用于资源授权（访问受保护API）的凭证。
• 但当请求的下游API与客户端应用（你的Web App）属于同一个AAD应用时，Easy Auth会认可id_token的有效性——因为id_token已经能证明用户身份，且应用上下文一致，所以会允许通过验证。这种情况属于Easy Auth针对同应用场景的特殊兼容，并非id_token的标准用途。

问题2：是否无需用户重认证即可刷新id_token？正确方案是什么？ #

关于id_token刷新的限制 #

/.auth/refresh端点确实仅支持刷新access_token，id_token本身无法通过该端点刷新——这是因为id_token设计为短生命周期的一次性身份凭证，不提供刷新机制。

可行的解决方案 #

1. 静默获取新的id_token
   若用户的Easy Auth会话Cookie仍有效（未过期），服务器端可以带着该Cookie请求身份提供商的登录端点（比如/.auth/login/aad），并附加prompt=none参数，触发静默认证流程：

   GET /.auth/login/aad?prompt=none
   

   这个请求会在用户无需交互的情况下，返回新的id_token（前提是用户的会话未失效，且身份提供商允许静默认证）。

2. 推荐：改用SPA直接获取access_token的规范流程
   你当前的Cookie模式并非SPA场景的最佳实践，更规范的方案是：

   • 让SPA采用授权码流+PKCE（针对公共客户端的标准OAuth2流程）直接从Azure AD获取access_token。
   • SPA使用Bearer令牌（在请求头Authorization: Bearer <access_token>）调用后端API，后端通过验证access_token的有效性来授权访问。
   • 这种方式下，SPA可以通过refresh_token正常刷新access_token，完全符合OAuth2资源访问的设计规范，也避免了Cookie模式可能带来的跨域、令牌管理复杂等问题。

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