OAuth 2与OAuth 1有何不同？

604

简单来说，有人可以解释OAuth 2和OAuth 1之间的区别吗？

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

oauth oauth-2.0 authorization

— 沙利文
source

请说清楚; stackoverflow.com/questions/9565744/...

— 学习者

如果您想查看OAuth的简要说明和详细流程图（包括图表），可以查看oauthbible.com

— Chris Ismael

您可以在这里找到答案OAuth 2.0-概述

— John Joe，

529

Eran Hammer-Lahav在解释OAuth 2.0简介中的大部分差异方面做得非常出色。总结一下，这是主要区别：

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

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

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

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

最后，OAuth 2.0旨在将负责处理OAuth请求的服务器与处理用户授权的服务器之间的角色完全分开。 有关上述内容的更多信息，请参见上述文章。

— villecoder
source

2

谁能澄清oauth 1和2之间的回调URL有何不同？

— Brian Armstrong

2

OAuth 2.0仅在被批准为RFC时才会弃用OAuth。目前它是一个Internet草案，但计划成为Internet标准（就这些事情而言）。但是，这将需要数年时间，因为尚未指定框架的大部分内容。未来几年，我们可能会看到一整个系列的互联网草案，每个草案都涉及OAuth 2.0授权框架的不同方面。要了解为什么如此，请访问tools.ietf.org/html/draft-ietf-oauth-v2，并搜索“超出本规范的范围”；）

— HåvardGeithus 2012年

48

这篇文章的作者去年写了一篇名为《 OAuth 2.0和地狱之路》的后续文章，可在此处阅读：web.archive.org/web/20120731155632/http : //hueniverse.com/2012/… 两者之间的显着差异是安全性-正如2.0版中缺乏密码学所预示的那样。

— kdazzle 2013年

4

OAuth 1.0的安全性取决于以下假设：可以将客户端应用程序中嵌入的秘密密钥保密，但是这种假设是天真的。在OAuth 2.0中，这样的天真客户端应用程序称为机密客户端。OAuth 1.0客户端和OAuth 2.0机密客户端之间的安全级别没有实际差异。“ OAuth 2.0和通往地狱的道路”错过了这一点。

— 川崎隆彦

6

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

— e_i_pi

193

我在这里看到了很好的答案，但是我想念的只是一些图表，由于我必须使用Spring Framework，因此我得到了他们的解释。

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

OAuth 2

在此处输入图片说明

OAuth 1

在此处输入图片说明

— x
source

3

在此流中，“ client_secret”在哪里使用？

— ashwintastic，

3

如果您是指用户在重定向到提供者（例如Facebook，Twitter，Google等）时输入的秘密，则这将是步骤2 OAuth 2和步骤4 OAuth 1。

— nyxz

为什么两个图都有一个称为“用户授予授权”的服务提供者步骤？这似乎是倒退或错误。“用户”不是寻求授权的人吗？

— 福宾

@Forbin因为此步骤发生在服务提供商的那一侧。您在他们的页面上，您会看到该服务要求您提供的赠款，并且您必须同意与您要进行身份验证的服务共享此信息。实际上，StackOverflow可以选择使用Google帐户登录。它的工作方式相同。因此，SO将要求Google查看您的电子邮件，您必须对此表示同意。

— nyxz

91

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

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

— chacham15
source

11

因此，基本上OAuth2可与HTTPS一起使用，因此比OAuth1更简单，后者需要更复杂，因为它无需HTTPS即可工作？

— 2015年

@MicroR这是您在那得到的一个实用定义！;）

— EralpB

36

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

一篇凄凉的文章

还有一个更技术的

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

关键点：

Oauth 2在SSL之上不提供安全性，而Oauth 1与传输无关。
从某种意义上说，SSL是不安全的，因为服务器不会验证连接，并且公共客户端库使忽略故障变得容易。

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

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

— 杰切林
source

4

“ typo”参数不是很有效-从http重定向到https是一种常见的做法

— Oleg Mikheev，2015年

2

@OlegMikheev是的，但是只需要一个http（no-s）请求就可以使MITM嗅探您的标头，并且您的令牌现在已被其他人使用！

— Patrick James McDougle

3

如果用标头来表示cookie，那么它们应该是安全的。除此之外，我看不到用户输入错误（在浏览器URL中）如何暴露令牌，甚至不应该将它们放在标头中

— Oleg Mikheev 2015年

2

作为针对“ typo”自变量的补充，服务提供商可以拒绝任何不是通过https进行的OAuth 2.0请求，并撤消该请求中的访问令牌。

— skeller88

32

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。

— 川崎孝彦
source

7

无论是通过HTTP，HTTPS还是其他方式发送机密而不是签名，由于MITM在协议级别上总是会带来隐性的安全风险。现在，有2种方法可以找到秘密，而不仅仅是1种：根设备或伪造根证书（以前已经发生过，所以并不牵强）。当您的安全模型是“ eh，让传输处理它”时，确实不会比该协议更安全。但是整体安全模型==许多服务的切入点。对于务实的工程师来说，它“足够好”，但是它永远不会像其他分散式模型那样“安全”。

— Mark G.

23

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

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

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

— 菲奥娜·米勒（Fionaa Miller）
source

22

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可能会产生不安全的实现。

— 托尼·尼克布
source

7

请注意，不鼓励仅链接的答案，随着时间的流逝，引用往往会过时。请考虑在此处添加独立的简介，并保留该链接作为参考。

— kleopatra 2013年

6

OAuth 1.0的安全性取决于以下假设：可以将客户端应用程序中嵌入的秘密密钥保密，但是对于智能手机应用程序而言，该假设是幼稚的。在OAuth 2.0中，这样的天真客户端应用程序称为机密客户端。OAuth 1.0客户端和OAuth 2.0机密客户端之间的安全级别没有实际差异。“ OAuth 2.0和通往地狱的道路”错过了这一点。

— 川崎隆彦

15

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

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

https://oauth.net/2/

如果您需要清楚地说明流量差异，则可以为您提供帮助：

OAuth 1.0流程

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

OAuth 2.0流程

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

来源：https : //codiscope.com/oauth-2-0-vs-oauth-1-0/

— 里查兹
source

2

您能看到粗体字的迹象吗？也许功能可以具有相同的概念，但是从技术上讲，使用简单的标头（oauth2）对整个请求进行签名非常不同。在分数答案无用之前要注意并提高阅读理解

— JRichardsz

1

请阅读您自己的答案并尝试理解它。“用秘密签名所有请求”和“用所有请求发送秘密”。除非他已经使用过它们，否则任何在他们头脑中正确的人都不会理解这里的区别。我知道区别，但OP不知道。这个答案只会进一步混淆OP，因此会降低投票率。如此含糊的答案值得谴责。请在这里阅读其他更具体，更有意义的答案。

— saran3h 19-10-23

12位开发人员获得了它。oauth1和oauth2有很多差异。先前的答案涵盖了这些内容，并且正如我所说，您可以阅读oauth.net/core/1.0a或oauth.net/2来做出自己的答案。我的目标是显示当开发人员需要开发其他客户时最臭名昭著的技术差异之一。

— JRichardsz

7

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

— 阿比吉特·盖克瓦德（Abhijit Gaikwad）
source

1

从安全角度来看，我会选择OAuth1。请参阅OAuth 2.0和通向地狱的道路

该链接的引言：“如果您当前正在成功使用1.0，请忽略2.0。它不能提供超过1.0的实际价值（我想您的客户端开发人员现在已经确定了1.0签名）。

如果您不熟悉此领域，并认为自己是安全专家，请在仔细检查2.0版的功能之后使用2.0。如果您不是专家，请使用1.0或复制您信任的提供程序的2.0实现以使其正确（Facebook的API文档是一个很好的起点）。2.0对于大规模而言是更好的选择，但是如果您要进行大型操作，则可能会在现场找到一些安全专家来为您解决所有问题。”

— 危害
source