OAuth 2与OAuth 1有何不同？

Question

简单来说，OAuth 2和OAuth 1有什么区别？

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

- sullivan

---

你可以在这里找到答案 OAuth 2.0 - 概述。 - John Joe

2023年，在大量使用OAuth之后，我有以下几点要说：

1. OAuth 2.0是当今最流行的OAuth标准版本。
2. OAuth 2.0解决了旧版OAuth 1标准中大部分已知的安全问题，因此您应该使用OAuth 2.0而不是旧版本。
3. OAuth 2.0似乎更偏向于授权码授权方式，而不是其他可能涉及通过HTTP请求发送用户登录详细信息的授权方式。

这是一篇最近的文章，解释了OAuth 2.0是什么，它的历史以及工作原理。 - undefined

Answer 1

Eran Hammer-Lahav在他的文章Introducing OAuth 2.0中对大部分差异进行了出色的解释。

*编辑：原链接于2023年8月13日报告失效。已更新为web.archive.org的快照*

总结一下，以下是主要的差异：

更多的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请求的服务器和处理用户授权的服务器之间实现清晰的角色分离。 关于此事的更多信息详见上述文章。

- villecoder

---

有人能解释一下OAuth 1和2之间的回调URL有什么不同吗？ - Brian Armstrong

OAuth 2.0只有在被批准为RFC时才会取代OAuth。目前它是一个互联网草案，但计划将其成为互联网标准（就这些事情而言）。然而，由于框架的大部分尚未指定，这将需要数年时间。我们可能会看到整个家族的互联网草案在未来几年内发布，每个草案都涉及OAuth 2.0授权框架的不同方面。要了解原因，请访问http://tools.ietf.org/html/draft-ietf-oauth-v2，并搜索“超出本规范的范围”;) - Håvard Geithus

这篇文章的作者去年写了一篇名为“OAuth 2.0 and the Road to Hell”的跟进文章，可以在这里阅读：https://web.archive.org/web/20120731155632/http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/两者之间一个重要的差异是安全性 - 这在2.0版本中缺乏加密时就已经预示了。 - kdazzle

OAuth 1.0的安全性依赖于假设嵌入客户端应用程序中的秘密密钥可以保密，但这个假设是幼稚的。在OAuth 2.0中，这样一个幼稚的客户端应用程序被称为“保密客户端”。OAuth 1.0客户端和OAuth 2.0保密客户端之间在安全级别上没有实际区别。“OAuth 2.0 and the Road to Hell”没有理解这一点。 - Takahiko Kawasaki

@kdazzle，该链接已移至此处：https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529。 - e_i_pi

Answer 2

我看到这里有很好的答案，但我错过了一些图表，因为我不得不使用Spring Framework，我遇到了他们的解释。

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

---

OAuth 2

---

OAuth 1

- nyxz

---

在这个流程中，“client_secret”在哪里使用？ - ashwintastic

如果你指的是用户在重定向到提供方（比如Facebook、Twitter、Google等）时输入的秘密信息，那么这将是"OAuth 2"的第2步，"OAuth 1" 的第4步。 - nyxz

为什么这两个图表都有一个名为“用户授权”的服务提供者步骤？这似乎是反向或错误的。难道不是“用户”正在寻求授权吗？ - Forbin

@Forbin 因为这一步是在服务提供商的侧面进行的。您正在他们的页面上，看到服务需要从您那里获得授权，并且您必须同意与您尝试进行身份验证的服务共享此信息。StackOverflow实际上有使用Google帐户登录的选项。它的工作方式相同。SO将要求Google查看您的电子邮件，您必须同意。 - nyxz

Answer 3

在我看来，之前的解释都过于详细和复杂了。简单来说，OAuth 2将安全性委托给HTTPS协议。而OAuth 1不需要这样做，因此必须采用替代方法来应对各种攻击。这些方法需要应用程序参与某些复杂的安全协议，实现起来可能很困难。因此，为了让应用程序开发人员不必担心安全问题，最简单的方法就是仅依靠HTTPS。

至于你的其他问题，答案取决于具体情况。有些服务不想要求使用HTTPS，而是在OAuth 2之前开发的，或者有其他要求使其无法使用OAuth 2。此外，关于OAuth 2协议本身已经有很多争议。正如你所看到的，Facebook、Google和其他一些公司都实现了略有不同的协议版本。因此，一些人坚持使用OAuth 1，因为它在不同平台上更加统一。最近，OAuth 2协议已经最终确定，但我们还没有看到它的采用情况。

- chacham15

---

基本上，OAuth2 使用 HTTPS 工作，因此比需要更复杂的 OAuth1 简单，因为 OAuth1 可以在没有 HTTPS 的情况下工作。 - Micro

@MicroR 这是一个非常实用的定义，你真棒！ ;) - EralpB

Answer 4

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 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 2.0的好理由。事实只是（1）OAuth 1.0只是针对机密客户端的规范，（2）OAuth 2.0简化了机密客户端的协议，并支持了公共客户端。无论是否被广泛认知，智能手机应用程序都被归类为公共客户端（RFC 6749, 9），这使得它们受益于OAuth 2.0。

- Takahiko Kawasaki

---

将密钥而非签名发送，无论是通过HTTP、HTTPS等方式，总会存在协议级别的中间人攻击隐患。现在有两种方法可以找到密钥而不仅仅是一种：对设备进行root操作，或伪造根证书（此前已经发生过，因此并非牵强附会）。如果你的安全模型是“嗯，让传输处理它”，那么它确实不会比协议本身更不安全。但是，在集中式的安全模型下，多个服务只有一个入口点。这对于务实的工程师来说“足够好”，但它永远不会像替代的分散式模型一样“安全”。 - Mark G.

Answer 5

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

一篇悲观的文章

以及一篇更加技术性的文章

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

关键点：

• Oauth 2在SSL之上没有提供额外的安全性，而Oauth 1是独立于传输的。

• 从某种意义上说，SSL并不安全，因为服务器不验证连接，常见的客户端库使忽略错误变得容易。

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

• 在OAuth 1.0中，您可以轻松地失误导致所有安全性丢失，而在OAuth 2.0中更难实现：

  第二个常见的潜在问题是打字错误。如果省略一个字符（例如“https”中的“s”）就会使令牌的整个安全性无效，您认为这是一种适当的设计吗？或者将请求（通过有效和经过验证的SSL/TLS连接）发送到错误的目标（例如“http://gacebook.com”？）。请记住，能够从命令行使用OAuth承载令牌显然是承载令牌倡导者推广的用例。

- djechlin

---

“typo”这个论点并不十分有效 - 将HTTP重定向到HTTPS是常见做法。 - Oleg Mikheev

是的，但只需一个非安全的HTTP请求就可以让中间人窃取您的标头信息，然后别人就可以使用您的令牌！ - Patrick James McDougle

如果您提到的“headers”是指“cookies”，那么它们应该是secure的。除此之外，我不明白用户在浏览器URL中输入错误会如何暴露令牌，因为令牌甚至不应该出现在头部信息中。 - Oleg Mikheev

反对“笔误”论点的另一个观点是，服务提供商可以拒绝任何不通过 HTTPS 发送的 OAuth 2.0 请求，并撤销该请求中的访问令牌。 - skeller88

Answer 6

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

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

这里 描述了 OAuth 1.0 和 2.0 的区别以及它们的工作方式。

- Fionaa Miller

Answer 7

OAuth 2显然是浪费时间（某位深度参与其中的人说）：

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

他说（为简洁起见编辑并加粗强调）：

...我不再能够与OAuth 2.0标准联系在一起了。我辞去了我的领导作者和编辑的角色，从规范中撤回了我的名字，并离开了工作组。将我辛苦劳作了三年，在两打草案中艰苦完成的文件中删除我的名字并不容易。决定放弃我已经领导了五年的努力是令人痛苦的。

...最后，我得出结论，OAuth 2.0是一个糟糕的协议。WS-*不好。它糟糕到我不想再与之相关联。...与OAuth 1.0相比，2.0规范更加复杂，互操作性更差，更少有用，更不完整，最重要的是，安全性更低。

明确一下，在深刻理解网络安全的开发人员的手中，OAuth 2.0可能会产生安全的实现。然而，在大多数开发人员手中 - 正如过去两年的经验所示 - 2.0很可能会产生不安全的实现。

- Tony Knibb

---

请注意，仅有链接的答案是不被鼓励的，因为参考文献随着时间的推移容易过时。请考虑在此添加一个独立的简介作为参考，同时保留链接作为参考资料。 - kleopatra

OAuth 1.0 的安全性建立在客户端程序中嵌入的秘密密钥可以保持机密的假设上，但在智能手机应用程序的情况下，这种假设是幼稚的。在 OAuth 2.0 中，这样幼稚的客户端应用程序被称为“保密客户端”。在OAuth 1.0客户端和OAuth 2.0保密客户端之间的安全级别没有实际差别。“OAuth 2.0和通往地狱之路”忽略了这一点。 - Takahiko Kawasaki

Answer 8

如果您需要更深入的解释，需要阅读两个规范文件：OAuth 1.0a和OAuth 2.0。正如您所见，它们之间有几个概念上的区别。如果您需要使用OAuth1或OAuth2消耗或发布某些服务，则以下是一个技术上的区别： OAuth 1.0流程：1)客户端应用程序向提供者（例如Twitter）注册； 2) Twitter向客户端提供一个唯一的“consumer secret”； 3)客户端应用程序使用其唯一的“consumer secret”对所有发送给Twitter的OAuth请求进行签名； 4)如果任何OAuth请求格式不正确、缺少数据或未经正确签名，则请求将被拒绝。 OAuth 2.0流程：1)客户端应用程序向提供者（例如Twitter）注册； 2)Twitter向客户端提供一个唯一的“client secret”； 3)客户端应用程序在每个请求中包含“client secret”，通常作为http头； 4)如果任何OAuth请求格式不正确、缺少数据或包含错误的密钥，则请求将被拒绝。来源：https://www.synopsys.com/blogs/software-security/oauth-2-0-vs-oauth-1-0/。

- JRichardsz

---

你能看到加粗的“signs”吗？也许“functional”有相同的概念，但从技术上讲，使用简单的“header”（oauth2）与对整个请求进行“签名”是非常不同的。在将答案标记为“无用”之前，请注意并提高阅读理解能力。 - JRichardsz

“Signs all request with secret” 和 “send secret with all requests” 的区别，除非已经使用过它们，否则正常人不会理解。我知道它们之间的区别，但提问者不知道。这个回答只会让提问者更加困惑，因此会被投反对票。这种含糊不清的回答应该被投反对票。请阅读其他更具体和信息丰富的答案。 - saran3h

有12位开发人员明白了。OAuth1和OAuth2有许多不同之处。以前的回答已经涵盖了它们，正如我所说，您可以阅读这个https://oauth.net/core/1.0a/或这个https://oauth.net/2/来得出您自己的答案。我的目标是展示一个最显著的技术差异，当一个开发人员需要开发REST客户端时。 - JRichardsz

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

- Abhijit Gaikwad

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更适合大规模使用，但如果您运营一个重要的业务，可能有一些安全专家在现场帮助您解决所有问题。”

- harmv