command-line - 授权命令行工具使用 Google API(通过 OAuth2.0 或其他任何方式)

Question

我想我了解 OAuth 2.0 在移动应用程序或网站的上下文中是如何工作的——我的情况也不是。

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

我有用户名。我有密码(用户输入的)。我需要获得一个 token ，这样我才能通过 Curl 调用电话。实现这一目标的最简单方法是什么？

更新 1:

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

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

每当我的命令行工具需要使用私有(private)资源时，该用户将需要提供 Google 提供的授权代码(然后我的命令行工具可以使用它来获取可用的 token )。如果用户没有在命令行中提供授权码，我的工具只会打印一个链接，用户可以将其粘贴到 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 token 进行 API 调用。

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

只是我，还是这整件事看起来像是疯狂的谈话，只是为了让我可以从命令行使用 Google API？

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

Answer 1

要回答有关“已安装应用程序”流程的问题:

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

刷新 token 是重要的标志。它使您可以无限制地访问 API，因为您可以使用它以编程方式获取新的 访问 token (有效期为 1 小时)。查看refresh token doc关于那个操作。

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

我的建议:

为您提供最佳用户体验的流程是使用服务器端 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 查询参数中的身份验证代码。您现在可以将身份验证代码交换为您保留的访问和刷新 token

杀死/关闭您在步骤 1 中启动的本地 Web 服务器

杀死/关闭您在步骤 2 中生成的浏览器实例

就是这样，您现在拥有了刷新和访问 token (来自第 4 步)，并且您在杀死浏览器后又回到了您的应用程序中。

为什么这一切都是一团糟？

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

OOB 替代方案

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

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