Google API：如何在不重定向的情况下进行身份验证？
当我们的最终用户在我们的网站上执行某些操作时，我们希望使用 Google Doc API 生成文档（在我们自己的企业帐户中）。
问题是我们已经尝试实现 OAuth 2.0 协议，如 v3.0 协议文档中建议的那样。 apiClient::authentication 方法执行重定向。这是一个主要问题，因为我们的用户不知道如何访问我们自己的企业帐户......而且我们无论如何也不想让他们访问；）
（换句话说，我们不会创建一个允许我们的用户可以编辑自己的数据，但可以与我们的数据（如数据库）进行交互。）
我读过 OAuth 2.0 的要点是避免我们管理用户的凭据。我个人对这个概念很满意，但在我们的例子中，我们不想在用户的谷歌帐户中进行身份验证......
那么，在没有来自用户的任何交互的情况下获得有效身份验证的最佳方法是什么？最终用户？
We want to use Google Doc API to generate Document (In our own business account) when our end users do some actions on our site.
The problem is that we've tried to implement the OAuth 2.0 protocol, as suggested in the v3.0 protocol documentation. The apiClient::authentication method do a redirection. This is a major problem because our users doesn't know the access to our own business account.... and we don't want to give them access anyway ;)
(In other word, we're not creating an application that allow our users to edit their own data, but to interact with our data, like a database.)
I've read that the point of OAuth 2.0 was to avoid that we manage the credential of our users. I'm personally O.K. with the concept, but in our case, we don't want to get authenticated in the google account of our users ...
So, what would be the best approach to get a valid authentication without any interaction from the end user ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您所描述的并不是 3 足 OAuth 的设计用途。
三足 OAuth 是关于委托身份验证，其中用户（知道其密码）可以向应用程序授予有限且可撤销的资源访问权限。该应用程序永远看不到用户的密码。要安全地允许应用程序冒充用户需要进行大量工作。
您可能想要的是使用（两条腿）OAuth 流程，其中 Consumer_id/consumer_secret 凭据嵌入到您的应用程序中。在这里，您的应用程序不会模拟您的最终用户，并且不会涉及浏览器重定向。
以下是有关在 Google Apps 中使用 2-legged OAuth 的一些详细信息：
http://googleappsdeveloper.blogspot.com /2011/07/using-2-legged-oauth-with-google-tasks.html
这是对 3 足 OAuth 与 2 足 OAuth 的良好描述：
http://cakebaker.42dh.com/ 2011/01/10/2-legged-vs-3-legged-oauth/
What you describe is not how 3-legged OAuth was designed to be used.
3-legged OAuth is all about delegated authentication where a user (who knows his password) can grant limited and revokable resource access to application. That application never sees the user's password. There is a bunch of work involved to safely allow the application to impersonate the user.
What you probably want is to use the (2-legged) OAuth flow, where the consumer_id/consumer_secret credentials are embedded in your application. Here your application is not impersonating your end user and there would be no browser redirection involved.
Here's some further info on using 2-legged OAuth in Google Apps:
http://googleappsdeveloper.blogspot.com/2011/07/using-2-legged-oauth-with-google-tasks.html
And this is a good description of 3- vs 2- legged OAuth:
http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/
您将需要使用服务帐户。基本上，您正在将此帐户的访问权限硬编码到您的服务器应用程序中。然后，您可以使用共享来授予对所需内容的访问权限。例如，您可以与服务帐户共享 Google 文档或 Analytics 配置文件。
以下是设置服务帐户、登录然后使用它的完整示例实现。
更新于 2018 年 12 月 12 日：https://gist.github.com/fulldecent/6728257
You will need to use a SERVICE ACCOUNT. Basically you are hard coding access to this account into your server application. Then you use sharing to give access to the to account for the content you want. For example you can share a Google Doc or an Analytics profile with the SERVICE ACCOUNT.
Here is a complete example implementation of setting up a service account, logging and and then using it.
Updated 2018-12-12: https://gist.github.com/fulldecent/6728257
为什么不为您的企业帐户获取一个 OAuth 授权并让所有用户都使用该帐户。由于听起来您希望每个人都访问一个帐户的数据，因此可以对最终用户隐藏详细信息。
访问令牌将由所有用户共享，并且他们都会访问同一帐户后端，而无需对每个用户自己的帐户进行任何授权。
Why not get one OAuth authorization for your business account and have all users use that account. Since it sounds like you want everyone accessing the data for one account, the details can be hid from the end user.
The access token would be shared by all users and they would all hit the same account back end without any authorization for each user's own account.