Google 刷新令牌会过期吗？
我在短时间内多次使用刷新令牌进行测试，但我想知道 Google 刷新令牌是否会过期？我可以长时间（一周甚至几个月）使用相同的刷新令牌来一次又一次地获取另一个访问令牌吗？
Google Auth 服务器发出的刷新令牌永不过期——这就是刷新令牌的全部意义所在。当用户撤销对您的应用程序的访问权限时，刷新令牌将过期（或者我应该说成为未经授权的）。
请参阅此 doc，它清楚地说明了刷新令牌的功能。
服务器可以发出一个短期访问令牌和一个长期刷新令牌，而不是发出一个长期有效的令牌（通常有效期为一年或无限期）。所以简而言之，您可以一次又一次地使用刷新令牌，直到授权访问的用户撤销对您的应用程序的访问。
这是一个非常令人困惑的线程。第一个答案似乎是正确的，但实际上并没有引用谷歌的任何权威。
我找到的最明确的答案实际上是在您获得令牌的开发者游乐场中。第 2 步底部有一个注释，上面写着：
“注意：OAuth Playground 不存储刷新令牌，但由于刷新令牌永不过期，如果用户想手动撤销它们，则应转到其 Google 帐户授权访问页面。”
https://developers.google.com/oauthplayground/
我遇到了同样的问题，后来发现我正在做的错误。将其发布在这里，以便其他人也可能会发现它有用。
可以从 Google 文档 Using OAuth 2.0 to Access Google APIs 的 Refresh token expiration 部分中读取以下内容：
为外部用户类型配置了 OAuth 同意屏幕且发布状态为“测试”的 Google Cloud Platform 项目会发出一个在 7 天后到期的刷新令牌。
如果项目发布状态为“测试”，则刷新令牌实际上会在 7 天后过期。根据谷歌文档：
为外部用户类型配置了 OAuth 同意屏幕且发布状态为“测试”的 Google Cloud Platform 项目会发出一个在 7 天后到期的刷新令牌。
我不认为这是完全正确的：
请注意，将发行的刷新令牌的数量是有限制的；每个客户端/用户组合一个限制，所有客户端的每个用户另一个限制。您应该将刷新令牌保存在长期存储中，并在它们保持有效时继续使用它们。如果您的应用程序请求太多刷新令牌，它可能会遇到这些限制，在这种情况下，较旧的刷新令牌将停止工作。
从这个页面：https://developers.google.com/youtube/v3/guides/authentication#installed-apps
这是来自 youtube 文档（我发现它比其他 api 文档要好得多），但我认为所有谷歌应用程序都是一样的。
规则在 2017 年的某个时候发生了变化，所以我认为最好的答案是它取决于产品。例如，在 Gmail API 上，Oauth 2.0 刷新令牌会在密码更改时过期。看到这个https://support.google.com/a/answer/6328616?hl=en
我们曾经在设置新的 gmail 用户时提前设置 API 访问并生成刷新令牌，然后我们可以归档他们的邮件（法律要求我们这样做），但现在一旦他们更改密码，刷新令牌被撤销。
也许对于 youtube、maps 来说，刷新令牌仍然是真正长寿的，但对于 gmail api，则指望一个短令牌。
看到这个：
在用户撤销访问之前，刷新令牌一直有效。仅当授权码请求中包含 access_type=offline 时，此字段才存在。
在https://developers.google.com/accounts/docs/OAuth2WebServer
从以下内容阅读：https://developers.google.com/identity/protocols/oauth2#expiration 您必须编写代码来预测授予的刷新令牌可能不再起作用的可能性。由于以下原因之一，刷新令牌可能会停止工作：
用户已撤消您应用的访问权限。刷新令牌已六个月未使用。用户更改了密码，并且刷新令牌包含 Gmail 范围。用户帐户已超过授予（实时）刷新令牌的最大数量。当前每个客户端的每个用户帐户限制为 50 个刷新令牌。如果达到限制，则创建新的刷新令牌会自动使最旧的刷新令牌失效，而不会发出警告。此限制不适用于服务帐号。
用户帐户或服务帐户在所有客户端上可以拥有的刷新令牌总数也有更大的限制。大多数普通用户不会超过此限制，但开发人员的测试帐户可能会。
对于个人项目，只需在 Google Console“Oauth Consent Screen”选项卡上提交应用程序以进行验证，以阻止令牌过期。如果您不想验证应用程序，则无需做任何进一步的事情。
刷新令牌的主要概念是持久且永不过期。
访问令牌有一个到期时间并且它会到期，一旦它到期，我们可以去获取刷新令牌，它将一次又一次地使用，直到用户从他的帐户中撤消。
为 OAuth 令牌设置较长的过期时间
在 OAuthv2 策略中为访问令牌和/或刷新令牌设置较长的过期时间会导致 OAuth 令牌的累积并增加 Cassandra 节点上的磁盘空间使用量。
以下示例 OAuthV2 策略显示刷新令牌的过期时间为 200 天：
<OAuthV2 name="GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
<RefreshTokenExpiresIn>17280000000</RefreshTokenExpiresIn> <!-- 200 days -->
<SupportedGrantTypes>
<GrantType>password</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
在上面的例子中：
访问令牌设置为 30 分钟的合理较低的到期时间。
刷新令牌设置为 200 天的非常长的过期时间。
如果此 API 的流量为 10 个请求/秒，那么它一天可以生成多达 864,000 个令牌。
由于刷新令牌仅在 200 天后过期，它们在数据存储（Cassandra）中持续存在很长时间，导致不断积累。
关注公众号
不定期副业成功案例分享
