ADFS的token响应中expires_in是否不符合OAuth2规范？

你的判断在逻辑上完全成立——从OAuth2规范对expires_in的定义来看，它应当代表从响应生成时刻到令牌过期的剩余秒数，也就是你提到的840秒（14分钟），而ADFS返回900秒的行为确实会导致依赖该字段的应用在最后60秒使用已过期的令牌。不过ADFS的这个行为是由它自身的设计逻辑决定的，核心要点如下：

• ADFS对expires_in的取值规则：ADFS的expires_in直接返回配置中设置的令牌总有效期（15分钟=900秒），而非实时计算响应时刻到令牌exp字段的剩余时间。它将expires_in视为令牌的“标称有效期”，而非动态的剩余时长。
• NotBeforeSkew的影响：NotBeforeSkew=1是为了缓解客户端与ADFS服务器的时钟偏差，让令牌的nbf（生效时间）提前1分钟，但令牌的总生命周期（从iat到exp）仍保持配置的15分钟。ADFS在返回expires_in时，并不会考虑nbf提前的影响，依然返回总配置值。
• 风险与解决方案：
  • 若应用仅依赖expires_in而不解析JWT，确实会出现最后60秒使用无效令牌的情况——此时令牌的exp已过期，但应用尚未触发刷新。
  • 最可靠的解决方式是强制应用解析JWT的exp字段来判断过期时间，这也是OAuth2/JWT规范推荐的最佳实践：令牌本身携带了exp这个权威的过期时间戳，无需依赖响应中的expires_in字段。
  • 若无法修改应用逻辑，目前公开的ADFS配置项中没有调整expires_in计算逻辑的选项，只能接受该风险，或联系微软技术支持确认是否有隐藏配置方案。

内容的提问来源于stack exchange，提问作者A. Baudat