第三方API的5分钟过期Bearer Token典型OAuth使用策略问询

针对这类5分钟有效期的Bearer Token，行业里的主流策略绝对不是每次调用前都去获取新Token，而是缓存Token并提前刷新，具体细节如下：

不推荐的做法：每次调用前获取新Token #

这种方式虽然能保证Token绝对有效，但完全是资源浪费：

• 会给第三方的Token颁发接口带来不必要的请求压力，高频调用甚至可能触发对方的限流机制
• 额外的Token请求会增加你的应用整体响应时间，拖慢用户体验

常规最优策略：缓存Token+提前刷新 #

这是绝大多数应用采用的标准方案：

• 缓存逻辑：获取到Token后，不要等到它刚好5分钟到期再换，而是预留10%-20%的有效期作为缓冲时间（比如5分钟有效期的话，缓存4分30秒或者4分钟）
• 刷新时机：当缓存的Token剩余有效期不足缓冲时间时，主动发起新的Token请求，替换掉即将过期的Token
• 额外优化：
  • 如果是多实例部署的应用，要用分布式缓存（比如Redis）来共享Token，避免每个实例重复请求Token
  • 要处理Token获取失败的异常场景：比如缓存过期但新Token拿不到时，可加入重试机制，或者暂时降级服务
  • 调用第三方API时如果返回401（Token失效），要立刻触发Token刷新并重试请求（作为兜底方案）

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