授权命令行工具使用 Google API（通过 OAuth2.0 或其他任何方式）

Posted 2023-03-04

【中文标题】授权命令行工具使用 Google API（通过 OAuth2.0 或其他任何方式）

【英文标题】：Authorizing command line tool to consume Google APIs (through OAuth2.0 or anything else)

【发布时间】：2012-10-30 08:35:42

【问题描述】：

我认为我了解 OAuth 2.0 在移动应用程序或网站环境中的工作原理 - 我也不是。

我有一个 C++ 命令行 应用程序，我想授予对其中一项 Google 服务 (Google Fusion Tables) 的访问权限，但我认为这个问题适用于任何 Google 服务，或者见鬼，也许还有任何必须处理 OAuth2 的命令行应用程序。

我有用户名。我有密码（用户输入的）。我需要获得一个令牌，这样我才能通过 Curl 拨打电话。最简单的方法是什么？

更新 1：

查看文档后，似乎最不痛苦的 OAuth2 流程将是 "Installed Application" 一个。

我的想法是，我的命令行工具将在不需要令牌的情况下发出对公共表的请求（但似乎我们仍然需要从 Google 发送 AppID，我可以从 Google API 仪表板获取）。

每当我的命令行工具需要使用私有资源时，该用户都需要提供 Google 提供的授权码（然后我的命令行工具可以使用它来获取可用的令牌）。如果用户没有在命令行中提供授权码，我的工具只会打印一个链接，用户可以将其粘贴到 URL 以生成授权码。链接如下所示：

https://accounts.google.com/o/oauth2/auth?scope=https://www.googleapis.com/auth/fusiontables&redirect_uri=urn:ietf:wg:oauth:2.0:oob&response_type=code&client_id=812741506391-h38jh0j4fv0ce1krdkiq0hfvt6n5amrf.apps.googleusercontent.com

一旦用户接受，她必须将该授权码粘贴到终端，以便命令行工具可以使用它。命令行工具将使用授权代码向 Google 请求 token，最后我可以使用 Google 令牌进行 API 调用。

我还不清楚一些事情。授权码会变吗？如果是这样，我似乎需要在某处保存令牌并刷新令牌，以便每次令牌过期时都可以重用刷新令牌。

只有我一个人，还是这整件事看起来像疯了一样，只是为了让我可以从命令行使用 Google API？

我通常会使用ClientLogin flow，但似乎一切都表明它很快就会被弃用。

【参考方案1】：

回答您关于“已安装应用程序”流程的问题：

授权码只有效一次。在您交换它之后 - 并获得一个 刷新令牌 和一个 访问令牌 - 它将不再可用。把它扔掉。它只是一次性使用，您不再需要它。您需要做的只是将 刷新令牌 保留/保存/持久保存在某个本地文件中以供重复使用。

刷新令牌是重要的令牌。它使您可以无限期地访问 API，因为您可以使用它以编程方式获取新的 访问令牌（有效期为 1 小时）。查看refresh token doc关于该操作的信息。

Google API 客户端库通常会自动且透明地为您处理令牌刷新，但由于我们没有 C++ 客户端库，因此您需要自己执行此操作。我们使用的一种技术是在向 API 发出请求时捕获 403 错误（这表明 访问令牌 无效），在这种情况下，我们会进行刷新以获取新的 访问令牌，然后自动重试最初失败的操作。

我的建议：

为您提供最佳用户体验的流程是使用服务器端 Web 应用程序流程。可以在已安装和/或命令行应用程序上使用它，尽管它的工作量更大。方法如下：

在用户机器上启动本地网络服务器，监听空闲端口（例如：http://127.0.0.1:7777） 生成一个 Web 浏览器窗口（或将其嵌入到您的应用中）将用户重定向到 Google OAuth 2.0 授权页面并将重定向 URI 设置为 http://127.0.0.1:7777 当用户授予应用程序访问权限时，它会被重定向到您在http://127.0.0.1:7777 监听的服务器。 在您的本地 Web 服务器上，您会获得 URL 查询参数中的身份验证代码。您现在可以交换身份验证代码以获取您保留的访问和刷新令牌 杀死/关闭您在步骤 1 中启动的本地 Web 服务器 杀死/关闭您在第 2 步中生成的浏览器实例

就是这样，您现在拥有了刷新和访问令牌（来自第 4 步），并且您在关闭浏览器后又回到了您的应用程序中。

为什么这么乱？

客户端登录已被弃用。它正在消失，并且不适用于较新的 API。谷歌不希望用户给你他们的密码，因为你可能想存储它，你可能会被黑客入侵:)) 此外，它让你可以访问太多信息，因为你可以用他们的 Google Checkout 帐户购买东西或更改密码以窃取他们的帐户。目前，从安全角度出发的唯一方法是使用像 OAuth2 这样的三足身份验证系统，并且不鼓励使用密码，以便用户摆脱将用户名和密码提供给第三方的习惯。当然，OAuth2 更难用于桌面/命令行应用程序...

OOB 替代方案

如果您不想或无法启动 Web 服务器来侦听代码，则可以使用 oob OAuth 流程。它通过简单地将oob 指定为重定向URI 来工作。在这种情况下，用户不会被重定向到给定的 URL，而是会看到一个页面，上面写着“这是您的身份验证代码。将其复制粘贴到您的应用程序中。”。在您的应用程序上，您可以简单地让您的用户将身份验证代码粘贴到文本字段中，然后瞧。这是一个更糟糕的用户体验，但在某些情况下可能会更强大，并且可以在更多环境中工作，尤其是低技术环境。

请注意，并非所有 OAuth 2 提供商都支持，但至少 Google 和 Facebook 支持。

【讨论】：

谢谢@Nivco。我考虑了服务器端 Web 应用程序流程。尽管如此，我发现很难证明编写网络服务器或添加新的网络服务器库依赖项来做到这一点。我想另一种选择是在用户登录之前轮询 Google 端点，但如果 没有，我不确定何时停止。不过，我会考虑围绕刷新令牌写一些东西。

我最终设计了一个将 OAuth2 身份验证逻辑与我的命令行界面分开的设计。一种工具的工作是获取 refresh_token（通过使用 OAuth2 流程之一）并输出带有刷新令牌的 txt 文件。命令行工具使用 OAuth txt 刷新令牌来完成它的工作。用户有责任将 OAuth 刷新令牌放在安全的地方，或者在不再需要时将其删除。

同时，不建议按照 (2) 中的建议将浏览器嵌入到应用程序中。 Google blocks this，因为嵌入式网页视图不可信。