27

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

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

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

更新1：

在浏览了文档之后，似乎最不痛苦的 OAuth2 流程将是“已安装的应用程序”流程。

我在想的是，我的命令行工具将在不需要令牌的情况下发出对公共表的请求（但似乎我们仍然需要从 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 请求令牌，最后，我可以使用 Google 令牌进行 API 调用。

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

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

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

4

1 回答 1

43

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

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

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

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

我的建议：

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

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

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

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

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

OOB 替代方案

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

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

于 2012-11-14T15:30:07.307 回答