如何在未经渐进式Web应用程序的用户持续明确同意的情况下使用Google API? [英] How to use Google APIs without continuously explicit user consent from a progressive web application?
问题描述
我有一个渐进式Web应用程序，该应用程序需要对Google Drive API拥有写权限，才能在在线时在后台上传用户正在创建(在线或离线)的数据(媒体文件).它确实不需要服务器(除了提供所需文件外，因此静态服务器就足够了)，所有工作都可以在Web应用程序客户端完成.
由于上传需要在后台进行，因此每当用户再次联机时(使用服务工作者和后台同步单发API)，访问令牌不足以满足我的需要(用户可以脱机/不在线)据我所知，不应将刷新令牌存储在Web应用程序客户端上，而是将刷新令牌存储在Web应用程序客户端上.即使是这样，我仍然需要客户端密码，这意味着我必须使用服务器(或将密码保存在Web应用程序客户端中，这是禁止的)，以刷新令牌.
似乎当前使用OAuth2方案的方式与无服务器渐进式Web应用程序不一致，否则我可能会遗漏一些东西.在这方面，我认为渐进式Web应用程序更像是Chrome应用程序，但是我必须在Google API控制台中为我的应用程序提供一个Chrome应用程序ID，我没有(也不想这样做)，并且Chrome应用程序使用Chrome身份API，用于获取令牌，我不打算使用(也不能).
我当前正在使用实际的Node.js服务器，该服务器负责授权步骤，将访问令牌和刷新令牌保留在数据库中，并在有要求时将现有或新的访问令牌返回给客户端.服务器在这里是多余的(并且我确实不需要存储该数据需要隐私策略)，我想使用客户端代码来做所有事情，而不必每次在后台上传时都不断地请求授权.
将刷新令牌保留在Web应用程序客户端上，而只是伸手到服务器上以实际刷新访问令牌(除了客户端机密之外，什么都不需要存储在服务器端)，但是就像我提到的那样，我了解不应将刷新令牌保留在Web应用程序一侧.
是否有一种安全可靠的方法来在没有服务器的情况下(或仅从服务器获取刷新令牌并将其返回给客户端并通过从客户端获取刷新令牌来刷新访问令牌的服务器)实现这一目标?
实际上非常简单，具体取决于用例的详细信息.
一个重要的事实是，一旦用户授予了您的应用程序许可，他就不必重新授予它.因此，您不需要每次在后台上传时都不断地请求授权".但是，唯一的限制是用户必须登录Google才能获得访问令牌.通常这不是问题，但是您的应用需要处理用户已从Google注销的情况，并提示登录.
所有详细信息都在这里 https://developers.google.com/identity/protocols/OAuth2UserAgent
我建议您避免使用Google JS库，因为(a)它对UX有其自己的见解，(b)并非考虑PWA编写的，(c)在移动设备上存在问题，并且(d)是封闭源代码因此，当它崩溃(偶尔发生)时，您的用户会陷入困境，直到Google对其进行修复.上面的页面详细介绍了OAuth端点，因此您可以轻松地直接使用它们.这样做的附带好处是，添加其他云存储帐户(AWS，Azure，Drop等)只是更改端点URL的一种情况.
我在PWA中使用的体系结构是使PWA提示一次(并且仅一次)以进行授权，然后将用户的Gmail地址存储在localStorage中.然后我有一个
隐藏的iframe，它使用login_hint中的gmail地址每小时轮询一次访问令牌.这意味着从不要求iframe呈现任何UX.唯一需要UX的时间是初始身份验证，这是不可避免的，如果用户已经退出Google，则每个会话一次.
您可能要处理的唯一其他情况是允许用户在多个Google帐户(例如个人帐户和工作域帐户)之间进行选择.
从广义上讲，请记住Google并未创建OAuth规范，因此他们几乎无法提供替代解决方案.在抽象级别上，身份验证要求其中一个用户在场，或者是用于永久令牌的安全存储(例如，在服务器上或在诸如Android之类的安全存储中).即使我们发明了OAuth 3，情况仍然如此.
I have a progressive web application that needs write-access to the Google Drive API for uploading data (media files) the user is creating (either online or offline) in the background while online. It does not really need a server (except for serving the required files, so a static server is sufficient), all of the work could be done on the web application client side.
Since uploading needs to happen on the background, whenever the user is online again (using a service worker and the background sync one-shot API), an access token is not enough for my need (the user can be offline/not use the web application for days) and a refresh token is not supposed to be stored on the web application client side, as far as I understand. Even if it were, I would still need the client secret, which means I have to use a server (or keep the secret within the web application client side, which is a no-no) in order to refresh the token.
It seems like the current ways of using the OAuth2 scheme are at odds with server-less progressive web applications, or I might be missing something. Progressive web applications are more like Chrome applications in this regard, I guess, but I have to supply a Chrome application ID in the Google API console for my application, which I do not (and do not intend to) have and Chrome applications use the Chrome identity API for getting the tokens, which I do not intend to use (and cannot).
I am currently using an actual Node.js server which takes care of the authorization step, keeps the access token and refresh token in a database and returns the existing or new access token to the client, whenever asked. The server is redundant here (and requires a privacy policy for this data which I really do not need to store), I want to do everything using client code, without continuously asking for authorization whenever I upload in the background.
Keeping the refresh token on the web application client side and just reaching out to the server for actually refreshing the access token (nothing must be stored in the server side except the client secret, which is fine), but like I mentioned, I understand the refresh token is not supposed to be kept on the web application side.
Is there a safe and secure way to implement this without a server (or with a server that only gets the refresh token and returns it to the client and refreshes the access token by getting the refresh token from the client)?
It's actually fairly simple, depending on the fine details of your use case.
An important factoid is that once a user has granted permission to your app, he will not have to re-grant it. So you don't need to "continuously asking for authorization whenever I upload in the background". However, the only constraint is that the user must be logged in to Google in order to obtain an Access Token. Normally this isn't an issue, but your app needs to deal with the scenario that a user has logged off from Google, and prompt for login.
All the details are here https://developers.google.com/identity/protocols/OAuth2UserAgent
I suggest avoid the Google JS library because (a) it has its own opinions about the UX, (b) wasn't written with PWAs in mind, (c) has issues on mobile, and (d) is closed source so when it breaks (as it does occasionally), your users are dead in the water until Google fixes it. The page above details the OAuth endpoints so you can easily use them directly. This has the side benefit that adding other cloud storage accounts (AWS, Azure, Drop, etc) is just a case of changing the endpoint URL.
The architecture I use in my PWA is to have my PWA prompt once (and once only) for authorization and then store the user's Gmail address in localStorage. I then have a
hidden iframe which polls once per hour for an Access Token, using the gmail address in a login_hint. This means the iframe is never required to present any UX. The only time UX is required is for the initial auth, which is of course unavoidable, and once per session if the user has logged out of Google.
The only other edge-case you might want to deal with is allowing the user to select between multiple Google accounts, say a personal account and a work domain account.
On a broader point, remember that Google didn't create the OAuth spec so there is little they can do to provide an alternative solution. At an abstract level, auth requires one of the user being present, or secure storage for a permanent token (eg on a server or within a secure store such as Android). Even if we invent OAuth 3, that will still be the case.
这篇关于如何在未经渐进式Web应用程序的用户持续明确同意的情况下使用Google API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
