我在短时间内就多次使用了刷新令牌进行测试,但是我不知道Google刷新令牌是否会过期?我可以使用相同的刷新令牌长时间(一周甚至几个月)一次又一次地获取另一个访问令牌吗?
我在短时间内就多次使用了刷新令牌进行测试,但是我不知道Google刷新令牌是否会过期?我可以使用相同的刷新令牌长时间(一周甚至几个月)一次又一次地获取另一个访问令牌吗?
Answers:
由Google Auth服务器颁发的刷新令牌永不过期-这就是刷新令牌的重点。当用户撤消对您的应用程序的访问权限时,刷新令牌将过期(或者我应该说变得未经授权)。
参考此文档,它清楚地说明了刷新令牌的功能。
服务器可以发行短期访问令牌和长期刷新令牌,而不是发行长期令牌(通常有效期为一年或无限期)。简而言之,您可以一次又一次使用刷新令牌,直到授权访问的用户撤消了对您的应用程序的访问。
这是一个非常令人困惑的线程。第一个答案似乎是正确的,但实际上并没有引用Google的任何权威。
我找到的最明确的答案实际上是在开发人员的操场上,您可以在其中获得令牌。步骤2在底部有一个注释,内容为:
“注意:OAuth Playground不存储刷新令牌,但是由于刷新令牌永不过期,因此,如果用户想要手动吊销它们,则应转到其Google帐户授权访问页面。”
我认为这并非完全正确:
请注意,对将要发出的刷新令牌的数量有限制;每个客户/用户组合一个限制,所有客户中每个用户一个限制。您应该将刷新令牌保存在长期存储中,并在它们仍然有效的情况下继续使用它们。如果您的应用程序请求太多刷新令牌,则可能会遇到这些限制,在这种情况下,较早的刷新令牌将停止工作。
在此页面上:https : //developers.google.com/youtube/v3/guides/authentication#installed-apps
那是来自youTube文档(我发现它比其他api文档要好得多),但我认为在所有Google应用程序中都是一样的。
看到这个:
刷新令牌在用户撤销访问权限之前一直有效。仅当授权码请求中包含access_type = offline时,此字段才存在。
在https://developers.google.com/accounts/docs/OAuth2WebServer中
规则在2017年的某个时候发生了变化,所以我认为最好的答案是它取决于产品。例如,在Gmail API上,Oauth 2.0刷新令牌会在更改密码后过期。请参阅此https://support.google.com/a/answer/6328616?hl=zh_CN
我们过去曾经预先设置API访问权限,并在设置新的gmail用户时生成刷新令牌,然后可以存档他们的邮件(法律要求这样做),但是现在,只要他们更改了密码,刷新令牌被撤销。
也许对于youtube,地图而言,刷新令牌确实确实存在很长,但是对于gmail api,则依靠短令牌。
刷新令牌的主要概念是它持久并且永不过期。
访问令牌有一个到期时间,它到期了,一旦到期,我们就可以申请刷新令牌,该刷新令牌将被反复使用,直到用户从其帐户中撤销为止。
请阅读以下内容:https : //developers.google.com/identity/protocols/oauth2#expiration 您必须编写代码以预期授予刷新令牌可能不再起作用的可能性。刷新令牌可能由于以下原因之一而停止工作:
用户已撤消您的应用访问权限。刷新令牌已经六个月没有使用了。用户更改了密码,刷新令牌包含Gmail范围。用户帐户已超过已授予(实时)刷新令牌的最大数量。当前,每个客户端每个用户帐户最多只能有50个刷新令牌。如果达到限制,则创建新的刷新令牌会自动使最旧的刷新令牌无效,而不会发出警告。此限制不适用于服务帐户。
用户帐户或服务帐户可在所有客户端上拥有的刷新令牌总数也有较大的限制。大多数普通用户不会超过此限制,但开发人员的测试帐户可能会超过此限制。
我进行了进一步的研究,似乎在第一个“脱机”请求期间,使用了Google访问令牌来检索刷新令牌。从此以后,将使用刷新令牌来发布新的访问令牌。这个想法是访问令牌是短期令牌,但是可以通过长期刷新令牌来更新。这消除了必须请求URL'code'变量的需要,该变量需要两个端点的方法,并且必须使用基于引用者的请求来启动:
http://www.jensbits.com/2012/01/09/google-api-offline-access-using-oauth-2-0-refresh-token/
一些REST API服务(例如Dropbox)会发布永久存在的访问令牌,但Google会发布短期访问令牌。贝宝(PayPal)采取了一种折衷办法,即允许在不执行URI引用来源的情况下检索访问令牌。这意味着无需单击链接即可启动该过程,从而可以检索访问令牌。Google的方法论意味着,仅应在需要使用的情况下调用API例程。本质上,调用是通过基于引用者的过程发起的。这是通过发行短期访问令牌或必须在链中刷新的访问令牌来控制的。这要求开发人员更仔细地考虑系统应该如何流动。