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