将刷新令牌交换为访问令牌时出现“invalid_grant”错误

Question

我在很多问题中都看到了这个问题，但到目前为止，似乎没有一个适用于我的情况。

我们遇到的问题是当我们尝试获取访问令牌时收到“invalid_grant”错误。这只发生在某些帐户上，但是当它发生时，在我查看的每种情况下，刷新令牌以前都有效，现在已经停止工作。这种情况经常发生，因为客户撤销访问权限（过去几周我们管理的近 20% 的渠道似乎已失效）。

请注意，我们有一个将视频上传到客户的 YouTube 频道的后端流程。

1. 我们使用 OAuth2 来获取刷新令牌，这里是我们发送的参数...

   范围 = "https://www.googleapis.com/auth/youtube", client_id = "", response_type = "代码", access_type = "离线", 批准提示=“强制”， redirect_uri = "http://www.us.com/OAuth/YouTube"

注意：对于 client_id，我们使用 Google API 管理器中的电子邮件地址（或者曾经是，我只是查看了它，但它不再存在）。我们曾经使用此页面中的客户端 ID，但这也给我们带来了问题。这改变了吗？我们现在应该使用此页面中的客户端 ID 吗？

1. 我们将返回的代码交换为刷新和访问令牌，并将刷新令牌存储在我们的数据库中。

2. 后端进程将刷新令牌交换为访问令牌，这就是我们似乎收到“invalid_grant”错误的地方。

保证在任何时候都只使用一个通道的访问令牌（不适用 25 个限制）。我们不存储访问令牌，每次处理频道时都会获得一个新令牌。

任何想法可能会发生什么？有什么要找的吗？请参阅上面有关客户端 ID 的注释。这可能与它有关，但我很犹豫是否尝试它，因为使用 API 管理器中的“客户端 ID”会导致问题。

Answer 1

保证在任何时候都只使用一个通道的访问令牌（不适用 25 个限制）。我们不存储访问令牌，每次处理频道时都会获得一个新令牌。

此陈述不正确：访问令牌可以在它们仍然有效的情况下（一个小时）使用任意多次。

答案：

"invalid_grant" 基本上意味着您的刷新令牌不再有效。该问题的唯一解决方案是再次请求访问并获得一个新的。问题应该是为什么它首先会过期。

假设用户没有撤​​销访问权限，并且在过去六个月内已使用刷新令牌请求新的访问令牌。这可能是它被覆盖的问题。

当用户对您的应用程序进行身份验证时，您将获得一个刷新令牌。此刷新令牌与您的应用程序的客户端 ID 和刚刚通过身份验证的用户相关联。如果该用户再次验证您的应用程序，您将获得另一个刷新令牌。同样，此刷新令牌与用户和您的项目客户端 ID 相关联。这两个刷新令牌都可以使用。您的用户最多可以继续执行此操作 25（请注意，我认为最近将其更改为 50，但我尚未使用所有 API 对其进行测试）一旦他们达到此幻数，第一个刷新令牌将过期，如果您尝试使用否则您将获得无效的资助。

唯一的解决方案是再次请求身份验证。始终保存用户授予您的应用程序的最新刷新令牌非常重要。如果（像我一样）您有一个应用程序存储在许多需要身份验证的服务器上。您将不得不告诉他们不要多次刷新它，否则他们将不得不返回并重新验证他们过期的第一个。

如果您的所有请求都发生这种情况。您还可以检查您的服务器是否与 (NTP) 同步，并且您在 post 字段中发送请求的有效负载。没有像 HTTP GET 那样附加到身份验证端点（在那里做过）。

Answer 2

以下是令牌停止工作并变为无效的可能原因：

• 用户已撤销访问权限。
• 令牌已六个月未使用。
• 用户更改了密码，并且令牌包含 Gmail 范围。
• 用户帐户已超过一定数量的令牌请求。

如您所见，不建议您在每次处理频道时都请求一个新的。正如Token expiration中提到的：

如果您需要授权多个程序、机器或设备，一种解决方法是将您授权的每个用户帐户的客户端数量限制为 15 或 20 个。如果您是 Google Apps 管理员，则可以创建其他管理员用户并使用它们来授权一些客户端。

关于client_ID的使用，通常需要调用Creating a Google API Console project and client ID中提到的登录API。

最后，这个 Google 网上论坛讨论 - OAuth 2.0 400 - error:invalid_grant and ideas? 也可能会有所帮助。