App Engine 和 Bigquery 身份验证答案

【问题标题】：App Engine and Bigquery authenticationApp Engine 和 Bigquery 身份验证
【发布时间】：2012-10-10 10:32:27
【问题描述】：

我们希望借助 Bigquery 和 Cloud Storage 服务实施分析工具。该工具应在 App Engine 上运行并公开 REST 接口，以便所有请求都通过该接口并随后转发到 Bigquery。授权对 Bigquery 的访问应基于 App Engine 服务帐户（App Identity API）。但是，我们还需要对工具客户端进行身份验证。客户端始终是另一个应用程序或服务，因此 OAuth 2.0 和基于 Web 浏览器的身份验证对我们来说是不可接受的。有没有办法实现这种身份验证并以某种方式将其与 Bigquery 和 Cloud Storage ACL 绑定？

考虑如下情况。我们域中的客户已获得 Google 帐户。它向我们的 REST 接口发送请求，并提供凭据（电子邮件和密码）以及其他详细信息。该工具对客户端进行身份验证并代表其向 Bigquery（或云存储）发送请求。如果客户端在没有正确权限（通过 Bigquery/Cloud Storage ACL 设置）的情况下尝试访问 Dataset（Bigquery）或 Bucket/Entity（Cloud Storage），则禁止访问。

【问题讨论】：

请解释一下“客户”：您说：a) 客户始终是另一个应用程序......并且 b) 客户在我们的域中获得了 Google 帐户。
好吧，我们假设可以在我们的域下创建一个 Google 帐户并使用帐户凭据（电子邮件、密码）来验证客户端（应用程序）。但是，我们可能错了，我们将不得不自己实现身份验证（例如通过 Spring Security）。我们考虑 Google 帐户主要是因为它们与 ACL 的连接。

标签： google-app-engine google-bigquery google-cloud-storage

【解决方案1】：

我认为我们都需要更多关于这个的细节。您如何向客户颁发凭据？您是否希望客户端的操作员知道您域上的用户名/密码来验证客户端对您的服务的身份？

一种选择可能是向客户端颁发 OAuth 2.0 刷新令牌，然后他们将该刷新令牌（安全地）放入他们的应用配置中，或者您在他们下载应用时自动捆绑它。除非被撤销，否则刷新令牌无限期有效。

然后将 OAuth 2.0 刷新令牌直接通过应用引擎应用传递到 BigQuery/Google Cloud Storage。然后可以在 Cloud Storage/BigQuery 中本地处理所有 ACL（哪个客户端有权访问什么）。

如果他们有凭据，您也可以让他们自己在网络浏览器中获取令牌。他们只需在设置应用程序时执行一次，令牌将由应用程序存储。有关将 OAuth 2.0 用于已安装应用程序的指南中的更多信息： https://developers.google.com/accounts/docs/OAuth2InstalledApp

【讨论】：

是的，我们希望客户端的操作员知道用户名/密码，但这些凭据应该在客户端设置（静态文件、数据库条目，...），而不需要 Internet 浏览器。
正如我在上面所写的，使用 Google 帐户的主要原因是它们与 ACL 的连接。但是，整个想法可能是错误的，我们将不得不实现自己的身份验证和 ACL 机制（Spring Security），这将更好地满足我们的需求。
请解释为什么要对凭据进行硬编码？这看起来像已安装应用程序的“旧”clientLogin，已被弃用。
好吧，如果有不同的方法可以在不使用浏览器的情况下对客户端进行身份验证，我们就不需要硬编码凭据。通常，大多数客户端将按计划作业运行，这就是为什么即使没有用户交互也需要进行身份验证的原因。
通常情况下，即使对于按计划作业运行的客户端，您也可以在设置过程中通过浏览器进行身份验证和授权。然后刷新令牌被无限期地存储和使用，除非/直到它被撤销。
这里很好地描述了如何将 OAuth 2 用于已安装的应用程序。 some 机器上需要一个网络浏览器进行设置，但之后不涉及网络浏览器：developers.google.com/accounts/docs/OAuth2InstalledApp