小开

最佳答案

GoogleAuth 服务器发布的刷新令牌永远不会过期ーー这就是刷新令牌的全部意义所在。当用户撤销对应用程序的访问时，刷新令牌将过期(或者我应该说成为未授权的)。

参考此医生，它清楚地说明了刷新令牌的功能。

代替发行长期持久的令牌(通常有效期为一年或无限期) , 服务器可以发出短期存在的访问令牌和长期存在的刷新令牌。因此，简而言之，您可以一次又一次地使用刷新令牌，直到授权访问的用户撤销对应用程序的访问。

小开

我不认为这是完全正确的:

请注意，将要发出的刷新令牌的数量有限制; 每个客户机/用户组合有一个限制，跨所有客户机的每个用户有另一个限制。您应该将刷新令牌保存在长期存储中，并在它们仍然有效时继续使用它们。如果应用程序请求了太多的刷新令牌，它可能会遇到这些限制，在这种情况下，旧的刷新令牌将停止工作。

来自本页: https://developers.google.com/youtube/v3/guides/authentication#installed-apps

这是来自 youTube 的文档(我发现它比其他的 api 文档要好得多) ，但我认为所有的谷歌应用程序都是一样的。

小开

看这个:

刷新令牌在用户撤销访问之前是有效的。只有在授权代码请求中包含 access _ type = off 时，才会出现此字段。

在 https://developers.google.com/accounts/docs/OAuth2WebServer

小开

刷新令牌的主要概念是它是持久的，永远不会过期。

访问令牌有一个过期时间，一旦过期，我们就可以使用刷新令牌，这个令牌将被一次又一次地使用，直到用户从他的帐户中撤消。

小开

这是一个非常混乱的线索。第一个答案似乎是正确的，但实际上并没有引用任何来自谷歌的权威。

我找到的最明确的答案实际上是在开发商的操场上，您可以在那里获得令牌。第二步在底部有一个注释说:

“注意: OAuth Playground 不存储刷新令牌，但由于刷新令牌永远不会过期，如果用户想手动取消刷新令牌，应该访问他们的 Google 帐户授权访问页面。”

Https://developers.google.com/oauthplayground/

小开

在2017年的某个时候，这方面的规则已经改变了，所以我认为最好的答案是，这取决于产品。例如，在 Gmail API 上，Oauth 2.0刷新令牌在密码更改时过期。看这个 https://support.google.com/a/answer/6328616?hl=en

我们过去常常提前设置 API 访问，在设置新 gmail 用户时生成刷新令牌，然后我们可以归档他们的邮件(法律要求我们这样做) ，但现在只要他们更改密码，刷新令牌就会被撤销。

也许对于 youtube，地图，刷新令牌仍然是真正长寿的，但是对于 gmail api，指望一个简短的令牌。

小开

请阅读以下 https://developers.google.com/identity/protocols/oauth2#expiration : 您必须编写代码以预测授予的刷新令牌可能不再工作的可能性。刷新令牌可能由于以下原因之一而停止工作:

用户已经取消了你的应用程序的访问权限。刷新令牌已有六个月没有使用了。用户更改了密码，刷新令牌包含 Gmail 作用域。用户帐户已经超过授予(活动)刷新令牌的最大数量。目前，每个客户端每个用户帐户的刷新令牌限制为50个。如果达到该限制，创建新的刷新令牌将自动使最旧的刷新令牌失效，而不会发出警告。此限制不适用于服务帐户。

对于一个用户帐户或服务帐户在所有客户端上可以拥有的刷新令牌的总数，还有一个更大的限制。大多数普通用户不会超过此限制，但开发人员的测试帐户可能会超过此限制。

小开

我经历了同样的问题，后来发现我正在做的错误。张贴在这里，以便其他人可能会发现它也有用。

以下内容可以从 Google 文档使用 OAuth 2.0访问 Google API的刷新令牌过期部分中读到:

一个 Google 云平台项目配置了一个 OAuth 同意屏幕，为外部用户类型配置了一个发布状态“测试”，该项目将发布一个刷新令牌，该令牌将在7天内到期。

小开

对于个人项目，只需提交谷歌控制台‘ Oauth 同意屏幕’选项卡上的应用程序进行验证，以阻止令牌过期。如果你不想验证应用程序，就不需要做任何进一步的工作。

小开

如果项目发布状态是“测试”，刷新令牌实际上会在7天后过期:

一个 Google 云平台项目配置了一个 OAuth 同意屏幕，为外部用户类型配置了一个发布状态“测试”，该项目将发布一个刷新令牌，该令牌将在7天内到期。

链接到引用

小开

为 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)中持续很长时间，从而导致持续累积。

Google 刷新令牌会过期吗？

为 OAuth 令牌设置较长的过期时间