无需用户交互处理Microsoft GraphAPI过期刷新令牌的方案咨询

为什么你的刷新令牌会过期（即使每日使用） #

你遇到的问题核心是对刷新令牌机制的误解：微软的单个刷新令牌最长生命周期就是90天，哪怕你每天用它获取access_token，90天后这个旧令牌还是会失效。而且每次用旧刷新令牌换取access_token时，API会返回一个新的刷新令牌，旧的令牌会立即失效。如果你一直保留并使用初始的那个刷新令牌，没有更新存储的令牌，90天到期后自然会触发过期报错，API返回的“不活动”属于误导性提示。

全自动化无手动认证的正确方案：刷新令牌轮换 #

这是最适合你当前场景的方案，完全不需要手动干预，核心是每次刷新都替换刷新令牌：

• 流程步骤：
  1. 每次调用Graph API前，先检查本地存储的access_token是否过期（通过响应里的expires_in字段计算过期时间）
  2. 如果access_token过期，调用POST /oauth2/v2.0/token端点，参数如下：

     grant_type=refresh_token
     client_id=你的应用ID
     client_secret=你的应用密钥
     refresh_token=当前存储的旧刷新令牌
     scope=初始授权时的权限范围（比如https://graph.microsoft.com/Mail.Read）
     

  3. 解析响应，将返回的新access_token和refresh_token立即更新到本地存储（比如数据库、加密配置文件），同时记录新的过期时间
  4. 使用新的access_token调用Graph API
• 注意：不要尝试“堆叠”刷新令牌——旧的刷新令牌在生成新令牌后会立刻失效，保留多个旧令牌没有任何意义，反而会增加维护风险。

更稳定的长期替代方案：客户端凭据流 #

如果你的项目是监控固定的服务邮箱，不需要模拟特定用户的操作，建议改用客户端凭据流，这是真正的无用户交互长期自动化方案：

• 配置步骤：
  1. 在Entra ID中给你的应用分配应用权限（而非委托权限），比如Mail.Read，并完成管理员同意
  2. 获取令牌时调用POST /oauth2/v2.0/token端点，参数如下：

     grant_type=client_credentials
     client_id=你的应用ID
     client_secret=你的应用密钥
     scope=https://graph.microsoft.com/.default
     

  3. 这种方式获取的access_token有效期通常为1小时，到期后直接用客户端凭据重新获取即可，不需要刷新令牌，全程无需任何手动操作

排查之前的“不活动”报错 #

可以从这几个方向确认：

• 检查是否真的每次都用刷新令牌获取新的access_token，还是一直在重复使用初始的access_token（如果access_token过期后才想起用刷新令牌，中间间隔可能超过90天）
• 登录Entra ID控制台，查看应用的令牌配置，确认是否设置了比90天更短的刷新令牌生命周期

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