2

我正在使用一个使用 OAuth2 的 API，它提供了一个在 3600 秒后过期的访问令牌，并提供了一个刷新令牌。最初，我等待 API 调用以表明访问令牌已过期的方式失败，然后尝试使用刷新令牌刷新访问令牌。当访问令牌过期并且同时进行多个 API 调用（每个调用单独触发刷新并且大多数调用失败）时，这已经成为问题。

3600秒后使用刷新令牌自动刷新访问令牌会更好吗？（或者 3599 秒还是 3601 秒？）我应该使用不同的范例来刷新访问令牌吗？

4

2 回答 2

1

理想情况下，客户端应该有足够的智慧来不使用过期的访问令牌。幸运的是，来自 OAuth AS 令牌端点的响应应包含 expires_in 属性，以确认到期时间为 3600 秒。例如：

{"token_type":"Bearer","expires_in":3600,"refresh_token":"p8BPdo01kkjh6fhatclD3wwBEQblm4kL4ctYRVlrHo","access_token":"9XebAAXeu6hQOAiwmOk8vdhRyUFV"}

由于此 JSON 响应是由服务器生成的，因此传输回客户端可能需要一些时间，因此“expires_in”值可能比它看起来的要小。

鉴于此，我建议您在到期前有某种缓冲区（例如 5-10 秒），以自动使用您的刷新令牌来请求新的访问令牌。

于 2012-08-28T15:51:18.013 回答
0

我可能使用了以下场景。由于访问令牌验证错误会导致访问失败，但这些错误将是最小的。

  1. App1 使用密码授权类型调用令牌 api 并获取访问令牌和刷新令牌对 (accto1/refto1)
  2. App2 在执行启动时也做同样的事情 (accto1/refto1)
  3. 当 App1 的访问令牌过期时，他可以通过调用具有刷新令牌授予类型和他现有的刷新令牌 (refto1) 的令牌 api 来执行刷新令牌，他将检索一对新的访问令牌和刷新令牌。(accto2/refto2)

  4. 当 App2 在其访问令牌过期时也到达实例时，他还将尝试使用他已经拥有的刷新令牌 (refto1) 授予刷新令牌，但由于该刷新令牌现已过期，他将收到授权错误。

  5. 当任何一个应用程序收到此错误时，应用程序需要意识到其他人已刷新令牌，因此此时应用程序需要使用密码授权进行调用以检索新的访问令牌/刷新令牌对。这一次，与示例中一样，App2 还将检索 App1 先前收到的用于其刷新令牌授权的相同访问令牌和刷新令牌对。(accto2/refto2)

于 2018-11-16T07:28:43.553 回答