645

用非常简单的术语，有人可以解释 OAuth 2 和 OAuth 1 之间的区别吗？

OAuth 1 现在过时了吗？我们应该实施 OAuth 2 吗？我没有看到很多 OAuth 2 的实现。大多数人仍在使用 OAuth 1，这让我怀疑 OAuth 2 是否可以使用。是吗？

4

10 回答 10

558

Eran Hammer-Lahav has done an excellent job in explaining the majority of the differences in his article Introducing OAuth 2.0. To summarize, here are the key differences:

More OAuth Flows to allow better support for non-browser based applications. This is a main criticism against OAuth from client applications that were not browser based. For example, in OAuth 1.0, desktop applications or mobile phone applications had to direct the user to open their browser to the desired service, authenticate with the service, and copy the token from the service back to the application. The main criticism here is against the user experience. With OAuth 2.0, there are now new ways for an application to get authorization for a user.

OAuth 2.0 no longer requires client applications to have cryptography. This hearkens back to the old Twitter Auth API, which didn't require the application to HMAC hash tokens and request strings. With OAuth 2.0, the application can make a request using only the issued token over HTTPS.

OAuth 2.0 signatures are much less complicated. No more special parsing, sorting, or encoding.

OAuth 2.0 Access tokens are "short-lived". Typically, OAuth 1.0 Access tokens could be stored for a year or more (Twitter never let them expire). OAuth 2.0 has the notion of refresh tokens. While I'm not entirely sure what these are, my guess is that your access tokens can be short lived (i.e. session based) while your refresh tokens can be "life time". You'd use a refresh token to acquire a new access token rather than have the user re-authorize your application.

Finally, OAuth 2.0 is meant to have a clean separation of roles between the server responsible for handling OAuth requests and the server handling user authorization. More information about that is detailed in the aforementioned article.

于 2010-11-08T17:02:08.377 回答
206

我在这里看到了很好的答案，但我错过了一些图表，因为我必须使用 Spring Framework，所以我遇到了他们的解释。

我发现下面的图表非常有用。它们说明了使用 OAuth2 和 OAuth1 的各方之间的通信差异。

认证 2

在此处输入图像描述

OAuth 1

在此处输入图像描述

于 2014-12-13T12:32:22.917 回答
106

前面的解释都是过于详细和复杂的IMO。简而言之，OAuth 2 将安全性委托给 HTTPS 协议。OAuth 1 不需要这样做，因此有替代方法来处理各种攻击。这些方法要求应用程序参与某些复杂且难以实施的安全协议。因此，仅依靠 HTTPS 进行安全性比较简单，应用程序开发人员无需担心。

至于你的其他问题，答案取决于。一些服务不想要求使用 HTTPS，它们是在 OAuth 2 之前开发的，或者有一些其他要求可能会阻止它们使用 OAuth 2。此外，关于 OAuth 2 协议本身存在很多争论。如您所见，Facebook、Google 和其他一些公司各自实施的协议版本略有不同。所以有些人坚持使用 OAuth 1，因为它在不同平台上更加统一。最近，OAuth 2 协议已经完成，但我们还没有看到它的采用情况。

于 2012-10-30T19:00:17.880 回答
39

请注意，使用 Oauth 2 存在严重的安全问题：

一篇惨淡的文章

和一个更具技术性的

请注意，这些来自 Oauth 2 的主要作者。

关键点：

  • Oauth 2 不提供 SSL 之上的安全性，而 Oauth 1 是独立于传输的。

  • 从某种意义上说，SSL 并不安全，因为服务器不验证连接，而通用客户端库很容易忽略故障。

    SSL/TLS 的问题在于，当您无法在客户端验证证书时，连接仍然有效。任何时候忽略错误导致成功，开发人员都会这样做。服务器无法强制执行证书验证，即使可以，攻击者也肯定不会。

  • 您可以轻而易举地消除所有安全性，这在 OAuth 1.0 中要难得多：

    第二个常见的潜在问题是拼写错误。当省略一个字符（“https”中的“s”）会使令牌的整个安全性失效时，您是否认为这是一种正确的设计？或者可能将请求（通过有效且经过验证的 SSL/TLS 连接）发送到错误的目的地（例如 '<a href="http://gacebook.com" rel="noreferrer">http://gacebook.com' ？）。请记住，能够从命令行使用 OAuth 不记名令牌显然是提倡使用不记名令牌的用例。

于 2013-03-01T22:04:59.703 回答
39

OAuth 1.0 协议 ( RFC 5849 ) 的安全性依赖于嵌入在客户端应用程序中的密钥可以保密的假设。然而，这种假设是幼稚的。

在 OAuth 2.0 ( RFC 6749 ) 中，这种天真的客户端应用程序称为机密客户端。另一方面，在难以保密密钥的环境中的客户端应用程序称为公共客户端。见2.1。客户类型以获取详细信息。

从这个意义上说，OAuth 1.0 是仅适用于机密客户端的规范。

《OAuth 2.0 与地狱之路》说 OAuth 2.0 的安全性较低，但 OAuth 1.0 客户端和 OAuth 2.0 机密客户端之间的安全级别没有实际差异。OAuth 1.0 需要计算签名，但如果已经确定客户端的密钥可以保密，则不会增强安全性。计算签名只是一个繁琐的计算，没有任何实际的安全增强。我的意思是，与 OAuth 2.0 客户端通过 TLS 连接到服务器并仅呈现client_id和的简单性相比client_secret，不能说繁琐的计算在安全性方面更好。

此外，RFC 5849 (OAuth 1.0) 没有提及任何关于开放重定向器的内容，而 RFC 6749 (OAuth 2.0) 则有。也就是说，oauth_callbackOAuth 1.0 的参数可能会成为一个安全漏洞。

因此，我认为 OAuth 1.0 并不比 OAuth 2.0 更安全。

[2016 年 4 月 14 日] 补充说明我的观点

OAuth 1.0 安全依赖于签名计算。使用密钥计算签名，其中密钥是 HMAC-SHA1 ( RFC 5849, 3.4.2 ) 的共享密钥或 RSA-SHA1 ( RFC 5849, 3.4.3 ) 的私有密钥。任何知道密钥的人都可以计算签名。因此，如果密钥被泄露，签名计算的复杂性无论多么复杂都毫无意义。

这意味着 OAuth 1.0 的安全性不依赖于签名计算的复杂性和逻辑，而仅依赖于密钥的机密性。换言之，OAuth 1.0 安全性所需要的只是密钥可以保密的条件。这听起来可能很极端，但如果条件已经满足，签名计算不会增加安全性增强。

同样，OAuth 2.0机密客户端依赖于相同的条件。如果条件已经满足，使用 TLS 创建安全连接并通过安全连接发送client_id和发送client_secret到授权服务器是否有任何问题？如果 OAuth 1.0 和 OAuth 2.0 机密客户端都依赖相同的条件，那么它们之间的安全级别是否有很大差异？

我找不到任何让 OAuth 1.0 归咎于 OAuth 2.0 的充分理由。事实很简单，(1) OAuth 1.0 只是一个仅适用于机密客户端的规范，(2) OAuth 2.0 也简化了机密客户端的协议并支持公共客户端。不管它是否广为人知，智能手机应用程序都被归类为公共客户端 ( RFC 6749, 9 )，它们受益于 OAuth 2.0。

于 2016-03-03T14:34:59.320 回答
28

生成令牌后，实际 API 调用不需要 OAuth 2.0 签名。它只有一个安全令牌。

OAuth 1.0 要求客户端为每个 API 调用发送两个安全令牌，并使用两者来生成签名。它要求受保护的资源端点可以访问客户端凭据以验证请求。

这里描述了 OAuth 1.0 和 2.0 之间的区别以及两者的工作方式。

于 2012-01-09T06:02:52.807 回答
26

OAuth 2 显然是在浪费时间（从一个参与其中的人的口中）：

https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a48f

他说（为简洁而编辑，为强调而加粗）：

...我无法再与 OAuth 2.0 标准相关联。我辞去了主要作者和编辑的职务，从规范中撤消了我的名字，并离开了工作组。从一份我辛苦工作了三年、两打草稿的文件中删除我的名字并不容易。决定从我领导了五年多的努力中继续前进是痛苦的。

...最后，我得出结论，OAuth 2.0 是一个糟糕的协议。WS-* 不好。这已经够糟糕了，我不想再与它联系在一起了。...与 OAuth 1.0 相比，2.0 规范更复杂，互操作性更低，用处更少，更不完整，最重要的是，安全性更低。

需要明确的是，OAuth 2.0 掌握在对 Web 安全有深入了解的开发人员手中，很可能会是一个安全的实现。然而，在大多数开发人员手中——就像过去两年的经验一样——2.0 可能会产生不安全的实现。

于 2013-06-28T11:59:22.600 回答
22
于 2017-04-10T14:40:00.763 回答
8

OAuth 2.0 承诺通过以下方式简化事情：

  1. 生成令牌所需的所有通信都需要 SSL。这大大降低了复杂性，因为不再需要那些复杂的签名。
  2. 生成令牌后，实际 API 调用不需要签名——这里也强烈建议使用 SSL。
  3. 生成令牌后，OAuth 1.0 要求客户端在每次 API 调用时发送两个安全令牌，并使用两者来生成签名。OAuth 2.0 只有一个安全令牌，不需要签名。
  4. 明确规定了协议的哪些部分由“资源所有者”实现，“资源所有者”是实现 API 的实际服务器，哪些部分可以由单独的“授权服务器”实现。这将使 Apigee 等产品更容易为现有 API 提供 OAuth 2.0 支持。

来源：http ://blog.apigee.com/detail/oauth_differences

于 2013-03-14T05:14:32.587 回答
2

从安全的角度来看，我会选择 OAuth 1。请参阅OAuth 2.0 和地狱之路。

引用该链接：

“如果您当前成功使用 1.0，请忽略 2.0。它没有提供超过 1.0 的实际价值（我猜您的客户端开发人员现在已经找到了 1.0 签名）。

如果您是这个领域的新手，并且认为自己是安全专家，请在仔细检查其功能后使用 2.0。如果您不是专家，请使用 1.0 或复制您信任的提供者的 2.0 实现以确保正确（Facebook 的 API 文档是一个很好的起点）。2.0 更适合大规模，但如果您正在运行一项大型操作，您可能会在现场有一些安全专家为您解决所有问题。”

于 2014-11-28T12:52:05.930 回答