Google OAuth 2.0离线访问 [英] Google OAuth 2.0 offline access

问题描述

即使用户不存在，我的应用也需要访问用户的数据.因此，我的授权码请求包含access_type=offline，这意味着如果这是用户首次验证我的应用程序，我将取回刷新令牌.我保存刷新令牌并在以后使用.

My app needs to access user's data even when the user is not present. So my request for authorization code includes access_type=offline meaning I will get back a refresh token if this is the first time the user authenticates my app. I save the refresh token and use it later on.

一切正常，效果很好.但令我困扰的是文档:

Everything works as expected and pretty well. But what bothers me is a statement in the documentation:

请注意，刷新令牌的数量受到限制 发行;每个客户/用户组合一个限制，每个客户每次使用的限制.您应该长期保存刷新令牌 存储并继续使用它们(只要它们仍然有效).如果你的 应用程序请求了太多刷新令牌，它可能会碰到这些 限制，在这种情况下，较早的刷新令牌将停止工作.

Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per use across all clients. You should save refresh tokens in long-term storage and continue to use them as long as they remain valid. If your application requests too many refresh tokens, it may run into these limits, in which case older refresh tokens will stop working.

如果我正确理解这一点，那么如果用户授权了太多应用程序，我保存的刷新令牌是否有可能变得无效?！这样对吗?在这种情况下，应用程序应如何应对?是否要求另一个刷新令牌?

If I understand this correctly, it is possible the refresh token I save to become invalid if the user authorizes too many applications?! Is this correct? How should the application react in such situations? Ask for another refresh token?

谢谢.

编辑:我创建了一个测试PHP脚本，该脚本将请求来自4个Google客户端的刷新令牌(按客户端，我指的是在Dev控制台中生成的凭据).其中三个链接到一个gmail地址，第四个链接到另一个.对于第一个电子邮件，我生成了2个项目，对于第一个项目，我生成了2个客户ID.所以:

I created a test PHP script that would request refresh tokens from 4 Google clients (by client I mean generated credentials in the Dev console). Three of them are linked to one gmail address and the forth to a different one. For the first email, I generated 2 projects and for the first project, I generated 2 client ids. So:

1. 发送电子邮件X，项目A，客户端ID abc
2. 发送电子邮件X，项目A，客户端ID def
3. 发送电子邮件X，项目B，客户端ID mno
4. 发送电子邮件Y，项目C，客户端ID xyz

1. email X, project A, client id abc
2. email X, project A, client id def
3. email X, project B, client id mno
4. email Y, project C, client id xyz

我通过为每个客户端请求刷新令牌来开始测试.然后，我为第一个客户端ID abc请求了24个其他刷新令牌.此时，即使对于电子邮件X我有27个刷新令牌，所有刷新令牌仍然有效.然后，当我为ID为abc的客户端请求另一个刷新令牌时，该客户端的第一个刷新令牌无效，因此每个电子邮件/客户端组合的令牌限制达到25个.所有其他令牌仍然有效，我设法为客户端def生成了新令牌.该客户端用于相同的项目A和相同的电子邮件X.所以我无法达到第二个极限.这些陈述对我来说仍然是完全的迷惑:

I started the test by requesting a refresh token for each client. Then I requested 24 more refresh tokens for the first client id abc. At this point all refresh tokens were valid even though for email X I had 27 refresh tokens. Then when I requested another refresh token for client with id abc, the first one for this client got invalidated, so hitting the 25 token limit per email/client combination. All other tokens were still valid and I managed to generate new tokens for client def. This client is for the same project A and the same email X. So I can't hit the second limit. What do these statements mean is still a complete mistery to me:

https://developers.google.com/accounts/docs/OAuth2#expiration

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

If you need to authorize multiple programs, machines, or devices, one workaround is to limit the number of clients that you authorize per user account to 15 or 20. If you are a Google Apps admin, you can create additional admin users and use them to authorize some of the clients.

https://developers.google.com/accounts/docs/OAuth2WebServer#refresh

请注意，刷新令牌的数量受到限制 发行;每个客户/用户组合一个限制，每个用户另一个限制 所有客户.

Note that there are limits on the number of refresh tokens that will be issued; one limit per client/user combination, and another per user across all clients.

推荐答案

它实际上并没有您想像的那么糟糕. 刷新令牌是特定于应用程序的，这意味着特定于您的客户ID.如果用户多次安装您的应用程序，则他们将具有与您的应用程序相关的许多刷新令牌.

It actually isn't as bad as you think. Refresh tokens are application specific, that meaning specific to your client id. If the user installs your application a number of times then they have a number of Refresh tokens related to your application.

如果用户的连接管理器在20个以上的SSIS软件包上运行，则我遇到了SSIS连接管理器的问题，第一个安装的软件包将停止工作.

I ran into this issue with a SSIS Connection manager if the user had my connection manager running on more then 20 SSIS packages the first one the installed would stop working.

https://developers.google.com/accounts/docs/OAuth2#expiration

Token expiration

You should write your code to anticipate the possibility that a granted token might
no longer work. 
A token might stop working for one of these reasons:

• 用户已撤消访问权限.
• 该令牌已经六个月没有使用了.
• 用户帐户已超过一定数量的令牌请求.

• The user has revoked access.
• The token has not been used for six months.
• The user account has exceeded a certain number of token requests.

每个Google用户帐户当前有25个令牌的限制.如果是用户 帐户有25个有效-令牌，下一个身份验证请求 成功，但在没有 任何用户可见的警告.

There is currently a 25-token limit per Google user account. If a user account has 25 valid - tokens, the next authentication request succeeds, but quietly invalidates the oldest outstanding token without any user-visible warning.

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

If you need to authorize multiple programs, machines, or devices, one workaround is to limit the number of clients that you authorize per user account to 15 or 20. If you are a Google Apps admin, you can create additional admin users and use them to authorize some of the clients.

只要同一用户的应用安装次数不超过15次，就不会有问题.如果有问题，您可以建议他们为您的应用程序使用其他/专用的登录名.

So as long as your application isn't being installed more then 15 times by the same user you shouldn't have a problem. If it is a problem you can suggest that they use a different / dedicated login for your application.

这篇关于Google OAuth 2.0离线访问的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！