1

目前，在 Web 服务 (Imgur) 的桌面应用程序中从 OAuth1 迁移到 OAuth2 的过程中，我对 OAuth2 规范感到困惑。根据此文档http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified并查看有关 OAuth2 的不同服务文​​档，显然它破坏了 OAuth1 提供的所有安全性。

使用 OAuth1，您可以使用用户授予访问权限的服务的 URL，并显示 PIN 以复制/粘贴到您的应用程序中，从用户永远不会向应用程序授予登录名/密码的意义上说，这是非常好的安全性，并且可以随时通过服务的网站撤销给定的访问权限。

现在使用 OAuth2，他们将这种情况排除在外，强制应用程序请求用户的登录名/密码，除非应用程序在其网站中制作自己的脚本以在授予访问权限后从服务接收令牌（然后让用户从你的网页）

我在这里错过了什么吗？

4

2 回答 2

0

桌面应用程序可以并且应该使用用户代理（浏览器）来执行 OAuth，这在 OAuth 2 规范中的“本机应用程序”下进行了描述。您描述的流程更适用于输入功能有限的设备，例如游戏机、打印机、相机等。

AFAIK，设备流程在 OAuth 2 的早期规范中，但在某些时候被省略了。无论如何，像 Google 这样的一些 API 提供商已经对它实施了有限的支持。

于 2012-12-20T21:07:18.687 回答
0

本机应用程序是要走的路。请参阅 OAuth 2.0 RFC 的 ["Native Applications"][1] 部分。本机应用程序不打算存储密码。如果您想避免直接在应用程序中输入凭据（即使在浏览器控件中），您可以从 OAuth 2.0 本机应用程序执行以下操作：

  1. 使用授权端点启动默认浏览器。
  2. 为您的重定向 URI 实现一个简单的网页，该网页选择授权代码并将其显示给用户。
  3. 要求用户复制代码并将其粘贴回本机应用程序。

或者，规范建议您利用本机平台的 URL 重定向方案来恢复原始应用程序。您可以查看 iOS 和 Android 的“URL Scheme”功能。不幸的是，这些平台都不能保证 URL 方案的唯一性，因此授权代码可能会被另一个在同一 URL 上激活的流氓应用程序劫持。我为此提交了一个 iOS 错误。[1]：https ://www.rfc-editor.org/rfc/rfc6749#page-52

于 2014-03-15T05:34:51.330 回答