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

时间:2015-06-14 06:56:12

标签: ios oauth-2.0

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

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

2 个答案:

答案 0 :(得分:53)

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

在定义中过期

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

  

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

令牌刷新处理:方法1

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

  1. expires_in转换为过期时间(纪元,RFC-3339 / ISO-8601日期时间等)
  2. 存储过期时间
  3. 在每个资源请求上,根据过期时间检查当前时间,并在资源请求之前发出令牌刷新请求access_token已过期
  4. 示例实现是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
    4. 刷新令牌过期

      如果您的refresh_token也已过期,则需要再次完成授权流程。

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

      一些示例包括LinkedIneBayRingCentral。在LinkedIn API中,当您刷新访问令牌时,您将收到一个刷新令牌,其{1}属性递减,目标是原始刷新令牌到期时间,直到您需要再次进行身份验证。 RingCentral API将返回具有静态时间的刷新令牌,因此如果令牌刷新并且刷新令牌更新一致,则用户无需再次进行身份验证。

答案 1 :(得分:0)

建议使用上面的方法2,因为401可能由于多种原因而发生,例如更新令牌签名证书或时钟差异:

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

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