如何识别OAuth令牌是否已过期？

Posted 2023-01-05

我的ios移动应用程序使用OAuth2.0协议实现的服务。 OAuth访问令牌附带刷新令牌和expires_in字段。我在我的应用程序中保存了刷新令牌和访问令牌到期时间，但不知道何时使用它们。

• 那么使用这个expires_in的常用和最佳做法是什么？
• 如何识别我的访问令牌已过期？
• 是否存在常见的Web服务错误格式，表明我的访问令牌已过期？

答案

以下是有关OAuth 2.0令牌刷新的信息。

在定义中过期

OAuth 2.0标准RFC 6749将expires_in字段定义为到期秒数：

expires_in：推荐。访问令牌的生命周期（以秒为单位）。例如，值“3600”表示访问令牌将在生成响应之后的一小时内到期。如果省略，授权服务器应该通过其他方式提供到期时间或记录默认值。

令牌刷新处理：方法1

在收到有效的access_token，expires_in值，refresh_token等后，客户可以通过存储到期时间并在每个请求上进行检查来处理此问题。这可以使用以下步骤完成：

1. 将expires_in转换为过期时间（epoch，RFC-3339 / ISO-8601 datetime等）
2. 存储过期时间
3. 在每个资源请求上，检查当前时间与过期时间，并在资源请求之前发出令牌刷新请求，如果access_token已过期

一个示例实现是Go oauth2库，它将expires_in值转换为令牌expiry property中的RFC 3339日期时间。 expiry不是由OAuth 2.0标准定义的，但在此处很有用。

在检查时间时，请确保您是同一时间，例如，通过将所有时间转换为纪元或UTC时区来使用相同的时区。

除了接收新的access_token，您可能会收到一个新的refresh_token，并且将来会有更长的到期时间。如果您收到此消息，则应存储新的refresh_token以延长会话的生命周期。

令牌刷新处理：方法2

处理令牌刷新的另一种方法是在收到无效令牌错误后手动刷新。这可以通过先前的方法或单独完成。

如果您尝试使用过期的access_token并且出现无效的令牌错误，则应执行令牌刷新（如果刷新令牌仍然有效）。由于不同的服务可以对过期的令牌使用不同的错误代码，您可以跟踪每个服务的代码，或者跨服务刷新令牌的简单方法是在遇到4xx错误时简单地尝试单次刷新。

无效的访问令牌错误

以下是热门服务的一些错误代码：

1. Facebook: Error 467 Invalid access token - 访问令牌已过期，已被撤销或无效 - 处理过期的访问令牌。
2. LinkedIn: Error 401 Unauthorized。
3. PayPal: Error 401 Unauthorized。

刷新令牌过期

如果您的refresh_token也已过期，您将需要再次完成授权过程。

OAuth 2.0 spec没有定义刷新令牌到期或如何处理它，但是，当刷新令牌到期时，许多API将返回refresh_token_expires_in属性。不同的API将以不同的方式处理刷新令牌过期，因此查看每个API的文档非常重要，但通常在刷新访问令牌时可能会收到新的刷新令牌。到期时应以类似的方式处理，例如将refresh_token_expires_in转换为RFC 3339日期时间refresh_token_expiry值。

一些例子包括LinkedIn，eBay和RingCentral。在LinkedIn API中，当您刷新访问令牌时，您将收到一个刷新令牌，其中refresh_token_expires_in属性递减，目标是原始刷新令牌到期时间，直到您需要再次授权为止。 RingCentral API将返回具有静态时间的刷新令牌，因此如果令牌刷新并且刷新令牌更新一致地完成，则用户不必再次进行身份验证。

另一答案

会推荐上面的方法2，因为401可能由于多种原因而发生，例如更新令牌签名证书或时钟差异：

• 在每个API请求后检查401
• 获取新令牌 - 仅限一次
• 重试API请求 - 仅限一次

我已经实现了大量成功的OAuth客户端并且一直使用这种技术 - 并且避免在我的客户端代码中读取expires_in字段