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