我正在使用一个使用 OAuth2 的 API,它提供了一个在 3600 秒后过期的访问令牌,并提供了一个刷新令牌。最初,我等待 API 调用以表明访问令牌已过期的方式失败,然后尝试使用刷新令牌刷新访问令牌。当访问令牌过期并且同时进行多个 API 调用(每个调用单独触发刷新并且大多数调用失败)时,这已经成为问题。
3600秒后使用刷新令牌自动刷新访问令牌会更好吗?(或者 3599 秒还是 3601 秒?)我应该使用不同的范例来刷新访问令牌吗?
我正在使用一个使用 OAuth2 的 API,它提供了一个在 3600 秒后过期的访问令牌,并提供了一个刷新令牌。最初,我等待 API 调用以表明访问令牌已过期的方式失败,然后尝试使用刷新令牌刷新访问令牌。当访问令牌过期并且同时进行多个 API 调用(每个调用单独触发刷新并且大多数调用失败)时,这已经成为问题。
3600秒后使用刷新令牌自动刷新访问令牌会更好吗?(或者 3599 秒还是 3601 秒?)我应该使用不同的范例来刷新访问令牌吗?
理想情况下,客户端应该有足够的智慧来不使用过期的访问令牌。幸运的是,来自 OAuth AS 令牌端点的响应应包含 expires_in 属性,以确认到期时间为 3600 秒。例如:
{"token_type":"Bearer","expires_in":3600,"refresh_token":"p8BPdo01kkjh6fhatclD3wwBEQblm4kL4ctYRVlrHo","access_token":"9XebAAXeu6hQOAiwmOk8vdhRyUFV"}
由于此 JSON 响应是由服务器生成的,因此传输回客户端可能需要一些时间,因此“expires_in”值可能比它看起来的要小。
鉴于此,我建议您在到期前有某种缓冲区(例如 5-10 秒),以自动使用您的刷新令牌来请求新的访问令牌。
我可能使用了以下场景。由于访问令牌验证错误会导致访问失败,但这些错误将是最小的。
当 App2 在其访问令牌过期时也到达实例时,他还将尝试使用他已经拥有的刷新令牌 (refto1) 授予刷新令牌,但由于该刷新令牌现已过期,他将收到授权错误。
当任何一个应用程序收到此错误时,应用程序需要意识到其他人已刷新令牌,因此此时应用程序需要使用密码授权进行调用以检索新的访问令牌/刷新令牌对。这一次,与示例中一样,App2 还将检索 App1 先前收到的用于其刷新令牌授权的相同访问令牌和刷新令牌对。(accto2/refto2)