OAuth 2 与 OAuth 1 有何不同？

Question

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

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

Answer 1

Eran Hammer-Lahav 在他的文章Introducing OAuth 2.0中解释了大部分差异方面做得非常出色。 总而言之，以下是主要区别：

更多的 OAuth 流程可以更好地支持非基于浏览器的应用程序。 这是非基于浏览器的客户端应用程序对 OAuth 的主要批评。 例如，在 OAuth 1.0 中，桌面应用程序或手机应用程序必须引导用户打开浏览器访问所需的服务，对服务进行身份验证，并将令牌从服务复制回应用程序。 这里的主要批评是针对用户体验。 借助 OAuth 2.0，应用程序现在有了新的方式来获得用户的授权。

OAuth 2.0 不再要求客户端应用程序具有加密。 这可以追溯到旧的 Twitter Auth API，它不需要应用程序使用 HMAC 哈希令牌和请求字符串。 使用 OAuth 2.0，应用程序可以仅使用已发布的令牌通过 HTTPS 发出请求。

OAuth 2.0 签名要简单得多。 不再需要特殊的解析、排序或编码。

OAuth 2.0 访问令牌是“短暂的”。 通常，OAuth 1.0 访问令牌可以存储一年或更长时间（Twitter 永远不会让它们过期）。 OAuth 2.0 具有刷新令牌的概念。 虽然我不完全确定这些是什么，但我的猜测是您的访问令牌可能是短暂的（即基于会话），而您的刷新令牌可能是“生命周期”。 您将使用刷新令牌来获取新的访问令牌，而不是让用户重新授权您的应用程序。

最后，OAuth 2.0 旨在在负责处理 OAuth 请求的服务器和处理用户授权的服务器之间明确分离角色。 有关更多信息，请参阅上述文章。

Answer 2

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

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

---

OAuth 2

---

身份验证 1

Answer 3

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

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

Answer 4

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

一篇黯淡的文章

和一个更具技术性的

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

关键点：

• Oauth 2 在 SSL 之上不提供任何安全性，而 Oauth 1 与传输无关。

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

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

• 您可以消除所有安全性，这在 OAuth 1.0 中要困难得多：

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

Answer 5

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

在 OAuth 2.0 ( RFC 6749 ) 中，这种简单的客户端应用程序称为机密客户端。 另一方面，在密钥难以保密的环境中的客户端应用程序称为公共客户端。 见2.1。 客户类型了解详情。

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

《 OAuth 2.0 and the Road to Hell 》说 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 1.0 的oauth_callback参数会成为一个安全漏洞。

因此，我不认为 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。

Answer 6

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

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

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

Answer 7

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

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

他说（为简洁起见进行了编辑，为强调而加粗）：

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

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

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

Answer 8

如果您需要一些高级解释，则需要阅读两个规范：

https://oauth.net/core/1.0a/

https://oauth.net/2/

正如您将看到的，有几个概念上的差异。

如果您需要使用 oauth1 或 oauth2 消费或发布某些服务，我在这里向您展示一个技术差异：

OAuth 1.0 流程

1. 客户端应用程序向提供程序注册，例如 Twitter。
2. Twitter 为客户提供该应用程序独有的“消费者秘密”。
3. 客户端应用程序使用其独特的“消费者秘密”签署对 Twitter 的所有 OAuth 请求。
4. 如果任何 OAuth 请求格式错误、数据丢失或签名不正确，该请求将被拒绝。

OAuth 2.0 流程

1. 客户端应用程序向提供程序注册，例如 Twitter。
2. Twitter 为客户端提供该应用程序独有的“客户端机密”。
3. 客户端应用程序包含“客户端机密” ，每个请求通常作为 http 标头。
4. 如果任何 OAuth 请求格式错误、缺少数据或包含错误的机密，则该请求将被拒绝。

资料来源：

• https://www.synopsys.com/blogs/software-security/oauth-2-0-vs-oauth-1-0/

Answer 9

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

Answer 10

从安全的角度来看，我会选择 OAuth 1。参见OAuth 2.0 和通往地狱的道路

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

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