使用 Sheets API 凭据分发程序

信息安全 验证 网络服务 oauth2 证书 谷歌应用
2021-08-22 20:42:31

我正在尝试编写一个使用 Google Sheets API 读取电子表格并对数据进行操作的程序。

我的程序包含credentials.json我从Java 快速入门页面(也可从Google Developers Console获得)获得文件没有它我无法使用 Sheets API。

我想将我的程序分发给一些消费者。但是,我不确定分发包含此credentials.json文件的程序有什么风险

有人认为他可以在这件事上启发我吗?是否有更安全的选择?

编辑:

查看当前的答案,似乎正确的方法是 OAuth 2.0。但是,同时查看Authorize Requests页面和Using OAuth 2.0 with the Google API Client Library for Java页面,我似乎仍然需要为我的应用程序添加一些标识,然后才能完成身份验证过程。我知道的唯一标识是 API 密钥以及客户端 ID 和客户端密钥对。

根据经验,我知道我不应该分发任何包含“秘密”一词的东西。话虽如此,我已经看到了其他应用程序 - 例如Stackexchange - 您可以授权访问您的帐户,并且它们都能够通过Google Sign In识别自己的身份。如果这些应用程序/站点可以在不存在任何安全风险的情况下向 Google 表明自己的身份,那么我相信我也可以这样做。

只有一个问题......我应该如何识别我的应用程序?

3个回答

我是谷歌 GDE 云平台,安全是我的专长。

您提到的 credentials.json 文件包含客户端 ID 和客户端密码。使用此凭据文件,攻击者可以为任何 Google Gmail/Gsuite/Identity 电子邮件地址创建凭据。这将允许任何有权访问这些机密的人创建具有他们想要的任何“范围”的凭据,并访问/读取/写入/删除表格、驱动器等中的数据。黑客可以托管木马软件或从您的帐户分发色情内容。因此,使用此文件分发您的应用程序是一个非常糟糕的主意。

正确的方法是在您的公共 Web 服务器上实施 OAuth 2.0,将访问令牌返回给用户。然后,用户将这个访问令牌包含在 HTTP 授权标头中。Google 表格会验证此令牌。这并不难做到,互联网上有很多例子。还有免费/几乎免费的服务,例如 Auth0 可以为您执行此操作。

[问题更新后更新]

做事有两种方法。简单的方法和安全的方法。我将讨论安全方法。

不要向客户提供任何形式的私人秘密。可以向客户端提供客户端 ID,因为这被视为公共机密。客户机密必须受到保护。

以下通常称为三足 OAuth。

这意味着 OAuth 在您的 Web 服务器(或第三方服务)上实现。客户永远不会看到秘密。客户端转到您网站上的页面,您的网站将用户重定向到 Google,Google 执行身份验证并使用令牌信息(访问令牌、ID 令牌、刷新令牌)回调您的 Web 服务器上的 URL。

为什么要以这种方式实现 OAuth?Google 表格要求 OAuth 令牌具有 OAuth 范围,并且您不希望允许客户端程序/浏览器指定范围。范围是权限。您必须控制客户端可以拥有的权限。

三足 OAuth 的对立面是两足 OAuth。这发生在浏览器中,不符合您的要求。

[关于两条腿 OAuth 的更新]

您的问题中未指定的一项是正在访问“谁的”数据。如果您的应用正在访问用户的私人数据,则该用户正在授予您的应用访问其数据的权限。如果您的应用程序正在访问您的私人数据,那么您正在授予用户访问您的数据的权限。

如果用例是您正在访问用户的数据,则两足 OAuth 是可以的(三足是最好的方法)。该方法可以完全在浏览器中实现。但是,对于所有 OAuth 方法,Google 要求您拥有经过验证的域名和网站供客户参考。这再次使三足 OAuth 成为正确的选择。

正如其他人所提到的,该credentials.json文件可以访问您的帐户。这不是你想与人分享的东西。但是有两点值得澄清:

与您的程序一起发布它与共享它是一回事

值得大声说,将其包含在您的程序中与共享它一回事。诚然,您的普通用户无法将其从您的应用程序中提取出来,但是对应用程序进行逆向工程以从中获取凭据不仅是完全可能的事情,而且是绝对会发生的事情。你不应该在你的应用程序中放置任何你不想与世界其他地方共享的东西。您不希望与世界其他地方共享此信息。诚然,在有人对您的应用程序进行逆向工程并窃取您的凭据之前可能需要很长时间,这不值得冒险。特别是因为:

无论如何,在您的程序中包含您的凭据对您的其他用户都不起作用

通过在程序中包含您的凭据,您正在制作一个仅适用于您的帐户的程序。显然这不是你想要做的。与您共享程序的人可能希望使用它来处理他们的数据,而不是您的数据。因此,即使忽略通过程序发布凭据所涉及的安全问题,如果您只是将凭据与程序一起分发,您就会遇到更实际的用户流程问题。简而言之,无论如何,这只是共享程序的错误身份验证方法。

解决方案

幸运的是,答案很简单:Google 支持的 OAuth2(如今它在几乎所有云服务提供商中都很常见)。OAuth“协议”是为这个特定的用例设计的。它旨在允许第三方应用程序(这是您构建的)获得对另一个用户帐户的有限访问权限,以代表他们执行操作,而无需实际询问用户他们的凭据。一个非常程式化(和简化)的流程如下所示:

  1. 用户打开您的应用并点击“登录”按钮。
  2. 您的应用通知 Google 您希望访问某人的帐户,并将用户发送到由 Google 托管的 OAuth 登录流程
  3. 此人使用其 Google 帐户登录 Google 的服务
  4. 然后,Google 会将它们与一个临时访问令牌一起引导回您的应用,您可以在所有 API 调用中使用该令牌
  5. 您可能还需要根据其最大年龄和用户保持登录的时间来刷新访问令牌。

然后可以安全地与您想要的任何人共享使用 OAuth 且没有您的凭据文件的程序版本。然后,当您自己使用该应用程序时,您将以与其他用户相同的方式登录。当然,如果您愿意,您也可以使用内置的凭据保留您的应用程序的原始版本。这将使您无需登录即可使用您的程序。但是,如果您这样做,请确保您不会意外与所有人共享它,因为它包含您的凭据。

凭证 json 文件是对服务帐户的完全访问令牌,此令牌可用于访问 gcp 帐户中的任何内容。假设您将此用户限制为通过 google 的 iam 操作您的帐户所需的最低限度,那么您是安全的。此外,我强烈建议将此用户置于所有其他 Google 项目或权限组之外。