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

How to identify if the OAuth token has expired?

提问by XiOS

My iOS mobile app consumes services that are implemented with the OAuth2.0 protocol. The OAuth access token comes along with a refresh token and an expires_infield. I saved the refresh token and access token expiration time in my app but don't have a good idea on when to use them.

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

• So what is the usual and best practice of using this expires_in?
• How do I identify that my access token is expired?
• Is there a common web service error format which says my access token is expired?

• 那么使用它的通常和最佳实践是expires_in什么？
• 如何确定我的访问令牌已过期？
• 是否有一种常见的 Web 服务错误格式表示我的访问令牌已过期？

回答by Grokify

Here's information on OAuth 2.0 token refresh.

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

Expires In Definition

到期定义

The OAuth 2.0 standard, RFC 6749, defines the expires_infield as the number of seconds to expiration:

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

expires_in: RECOMMENDED. The lifetime in seconds of the access token. For example, the value "3600" denotes that the access token will expire in one hour from the time the response was generated. If omitted, the authorization server SHOULD provide the expiration time via other means or document the default value.

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

Token Refresh Handling: Method 1

令牌刷新处理：方法一

Upon receiving a valid access_token, expires_invalue, refresh_token, etc., clients can process this by storing an expiration time and checking it on each request. This can be done using the following steps:

在接收到一个有效的access_token，expires_in值，refresh_token等等，客户端可以通过存储的到期时间，并检查它在每次请求处理此。这可以使用以下步骤完成：

1. convert expires_into an expire time (epoch, RFC-3339/ISO-8601 datetime, etc.)
2. store the expire time
3. on each resource request, check the current time against the expire time and make a token refresh request before the resource request if the access_tokenhas expired

1. 转换expires_in为过期时间（纪元、RFC-3339/ISO-8601 日期时间等）
2. 存储过期时间
3. 每个资源请求，查看当前的时间对到期时间，使资源请求之前令牌刷新请求是否access_token已过期

An example implementation is the Go oauth2library which converts the expires_invalue to a RFC 3339 date-time in the Token expiryproperty. expiryisn't defined by the OAuth 2.0 standard but is useful here.

一个示例实现是 Gooauth2库，它将expires_in值转换为 Tokenexpiry属性中的 RFC 3339 日期时间。expiry不是由 OAuth 2.0 标准定义的，但在这里很有用。

When checking the time, be sure you are the same time, for example, using the same timezone by converting all times to epoch or UTC timezone.

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

In addition to receiving a new access_token, you may receive a new refresh_tokenwith an expiration time further in the future. If you receive this, you should store the new refresh_tokento extend the life of your session.

除了收到一个新的之外access_token，您refresh_token将来可能还会收到一个过期时间更长的新。如果您收到这个，您应该存储新的refresh_token以延长会话的寿命。

Token Refresh Handling: Method 2

令牌刷新处理：方法 2

Another method of handling token refresh is to manually refresh after receiving an invalid token error. This can be done with the previous approach or by itself.

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

If you attempt to use an expired access_tokenand you get an invalid token error, you should perform a token refresh (if your refresh token is still valid). Since different services can use different error codes for expired tokens, you can either keep track of the code for each service or an easy way to refresh tokens across services is to simply try a single refresh upon encountering a 4xx error.

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

Invalid Access Token Errors

无效的访问令牌错误

Below are some error codes from popular services:

以下是一些流行服务的错误代码：

1. Facebook: Error 467 Invalid access token- Access token has expired, been revoked, or is otherwise invalid - Handle expired access tokens.
2. LinkedIn: Error 401 Unauthorized.
3. PayPal: Error 401 Unauthorized.

1. Facebook：错误 467 无效的访问令牌- 访问令牌已过期、被撤销或无效 - 处理过期的访问令牌。
2. LinkedIn：错误 401 未经授权。
3. 贝宝：错误 401 未经授权。

Refresh Token Expiration

刷新令牌到期

If your refresh_tokenhas also expired, you will need to go through the authorization process again.

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

The OAuth 2.0 specdoesn't define refresh token expiration or how to handle it, however, a number of APIs will return a refresh_token_expires_inproperty when the refresh token does expire. Different APIs will handle refresh token expiration differently so it's important to review the docs per API, but generally you may receive a new refresh token when you refresh your access token. Expiration should be handled in a similar way such as converting refresh_token_expires_into a RFC 3339 date-time refresh_token_expiryvalue.

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

Some examples include LinkedIn, eBay, and RingCentral. In the LinkedIn API, when you refresh access tokens, you will receive a refresh token with a decreasing refresh_token_expires_inproperty targeting the original refresh token expiry time until you are required to auth again. The RingCentral API will return refresh tokens with a static time so the user does not have to auth again if token refreshes and refresh token updates are done consistently.

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

回答by Gary Archer

Would recommend Method 2 above since a 401 can happen for multiple reasons such as renewing a token signing certificate or clock differences:

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

• Check for a 401 after every API request
• Get a new token - once only
• Retry the API request - once only

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

I've implemented plenty of successful OAuth clients and have always used this technique - and avoided ever reading the expires_in field in my client side code

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