OAuth 2 与 OAuth 1 有何不同？答案

【问题标题】：How is OAuth 2 different from OAuth 1?OAuth 2 与 OAuth 1 有何不同？
【发布时间】：2011-05-06 01:31:11
【问题描述】：

谁能简单的解释一下 OAuth 2 和 OAuth 1 的区别？

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

【问题讨论】：

你可以在这里找到答案OAuth 2.0 - Overview

【解决方案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 请求的服务器和处理用户授权的服务器之间的角色明确分离。 上述文章中详细介绍了有关这方面的更多信息。

【讨论】：

有人能澄清一下 oauth 1 和 2 之间的回调 url 有何不同吗？
OAuth 2.0 只有在被批准为 RFC 时才会淘汰 OAuth。目前它是一个互联网草案，但它计划成为一个互联网标准（只要这些事情可以规划）。然而，这将需要数年时间，因为框架的大部分内容尚未指定。未来几年，我们可能会看到一系列互联网草案的发布，每一个都涉及 OAuth 2.0 授权框架的不同方面。要了解为什么这是真的，请访问tools.ietf.org/html/draft-ietf-oauth-v2，并搜索“超出本规范范围”；）
该文章的作者去年写了一篇后续文章，名为《OAuth 2.0 与地狱之路》，可以在这里阅读：web.archive.org/web/20120731155632/http://hueniverse.com/2012/…两者的一个显着区别是安全性——as预示着 2.0 中缺乏密码学。
OAuth 1.0 的安全性依赖于嵌入在客户端应用程序中的密钥可以保密的假设，但这种假设是幼稚的。在 OAuth 2.0 中，这种幼稚的客户端应用程序称为机密客户端。 OAuth 1.0 客户端和 OAuth 2.0 机密客户端之间的安全级别没有实际差异。 “OAuth 2.0 和地狱之路”忽略了这一点。
@kdazzle，该链接现已移至此处：hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

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

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

【讨论】：

所以基本上 OAuth2 与 HTTPS 一起工作，因此比 OAuth1 更简单，因为它可以在没有 HTTPS 的情况下工作，所以需要更复杂一些？
@MicroR 这是您在那儿得到的一个实用定义！ ;)

【解决方案4】：

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

one bleak article

and a more technical one

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

关键点：

Oauth 2 不提供 SSL 之上的安全性，而 Oauth 1 独立于传输。
从某种意义上说，SSL 并不安全，因为服务器不验证连接，而通用客户端库很容易忽略故障。

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

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

【讨论】：

"typo" 参数不是很有效——通常的做法是从 http 重定向到 https
@OlegMikheev 是的，但是只需要一个 http（no-s）请求就可以让 MITM 嗅探您的标头，并且您的令牌现在正被其他人使用！
如果标题是指cookie，那么它们应该是secure。除此之外，我看不到用户拼写错误（在浏览器 URL 中）如何暴露令牌，它们甚至不应该在标题中
作为针对“typo”参数的附加点，服务提供商可以拒绝任何不通过 https 的 OAuth 2.0 请求并撤销该请求中的访问令牌。

【解决方案5】：

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

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

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

【讨论】：

【解决方案6】：

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 掌握在具有深度的开发人员手中对网络安全的理解可能会导致安全执行。然而，在大多数开发人员手中——正如过去两年的经验——2.0可能会产生不安全的实现。

【讨论】：

请注意，不鼓励仅链接的答案，参考随着时间的推移往往会变得陈旧。请考虑在此处添加独立的概要，并保留链接作为参考。
OAuth 1.0 的安全性依赖于嵌入在客户端应用程序中的密钥可以保密的假设，但在智能手机应用程序的情况下，这种假设是幼稚的。在 OAuth 2.0 中，这种幼稚的客户端应用程序称为机密客户端。 OAuth 1.0 客户端和 OAuth 2.0 机密客户端之间的安全级别没有实际差异。 “OAuth 2.0 和地狱之路”忽略了这一点。

【解决方案7】：

从安全的角度来看，我会选择 OAuth 1。请参阅 OAuth 2.0 and the road to hell

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

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

【讨论】：

【解决方案8】：

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

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

OAuth 2

OAuth 1

【讨论】：

在这个流程中，“client_secret”在哪里使用？？
如果您指的是用户在重定向到提供者（例如 Facebook、Twitter、Google 等）时输入的密码，那么这将是 OAuth 2 的第 2 步和OAuth 1 的第 4 步。
为什么两个图表都有一个名为“用户授予授权”的服务提供者步骤？这似乎是倒退或错误的。 “用户”不是在寻求授权吗？
@Forbin 因为此步骤发生在服务提供商方面。您在他们的页面上可以看到该服务需要您提供的授权，并且您必须同意与您尝试进行身份验证的服务共享此信息。 StackOverflow 实际上可以选择使用 Google 帐户登录。它的工作方式相同。 SO 会要求 Google 查看您的电子邮件，您必须同意。

【解决方案9】：

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

在 OAuth 2.0 (RFC 6749) 中，这种天真的客户端应用程序被称为机密客户端。另一方面，在难以保密密钥的环境中的客户端应用程序称为公共客户端。详情请见2.1. Client Types。

从这个意义上说，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) 没有提及任何关于 open redirectors 的内容，而 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 简化了机密客户端的协议并支持 public 客户端。不管它是否广为人知，智能手机应用程序都被归类为公共客户端 (RFC 6749, 9)，它们受益于 OAuth 2.0。

【讨论】：

发送秘密而不是签名，无论是通过 HTTP、HTTPS 等，由于协议级别的 MITM，总是会带来隐含的安全风险。现在有 2 种方法可以找到秘密，而不仅仅是 1：root 设备，或伪造 root 证书（以前发生过，所以并不牵强）。当您的安全模型是“嗯，让传输处理它”时，它确实不会比协议更安全。但是单一的安全模型 == 许多服务的一个入口点。对于务实的工程师来说，它“足够好”，但它永远不会像替代分散模型那样“安全”。

【解决方案10】：

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

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

https://oauth.net/2/

如您所见，存在一些概念差异。

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

OAuth 1.0 流程

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

OAuth 2.0 流程

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

来源：

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

【讨论】：

您能看到标志粗体字吗？也许功能可能具有相同的概念，但从技术上讲，使用简单的 header (oauth2) 与 sign 整个请求非常不同。在将答案标记为无用之前注意并提高您的阅读理解能力
请阅读您自己的答案并尝试理解它。 “用秘密签署所有请求”和“用所有请求发送秘密”。除非他已经使用过它们，否则没有人会理解这里的区别。我知道区别，但 OP 不知道。这个答案只会进一步混淆OP，因此会否决。如此含糊的答案值得一票否决。请在此处阅读其他更具体和信息丰富的答案。
12 个开发者知道了。 oauth1 & oauth2 有很多不同之处。以前的答案涵盖了它们，正如我所说的，您可以阅读此oauth.net/core/1.0a 或此oauth.net/2 来做出您自己的答案。我的目标是在开发人员需要开发休息客户端时展示最臭名昭著的技术差异之一。