我认为 OAuth 1.0 已经被 OAuth 2.0 弃用是对的吗？答案

【问题标题】：Am I right in thinking OAuth 1.0 has been deprecated in favour of OAuth 2.0?我认为 OAuth 1.0 已经被 OAuth 2.0 弃用是对的吗？
【发布时间】：2013-07-14 19:26:15
【问题描述】：

我在 Internet 上寻找一些关于这方面的信息，最后找到了 Oauth 1.0 协议的 RFC：https://www.rfc-editor.org/rfc/rfc5849

您可以阅读其顶部的“Obsoleted by: 6749”，如果您点击该链接，您最终将获得 OAuth 2.0 授权框架 RFC。

基于此，我可以安全地推断 OAuth 1.0 已被弃用，取而代之的是 OAuth 2.0？

谢谢。

【问题讨论】：

1.0 出于安全原因绝对不推荐使用，1.0a 仍然可用，实际上，在使用中（例如 Tweeter 使用 1.0a：dev.twitter.com/docs/auth/oauth）恕我直言，你不应该给 500 这样的问题:-)
@Simon “你不应该为这样的问题给出 500”——我完全同意。
@dan 那你为什么这么做，丹？我只是好奇。我猜这个 anfab 家伙很幸运 XD
@chris - 我一直在为雇用我的公司写一份重要的研究文件，我真的很想做得很好 - 这个问题是关键问题之一。
@chris：我没有得到赏金 :-) 我同意 500 对于这个问题来说太多了

标签： oauth oauth-2.0

【解决方案1】：

是和否。

IETF 发布了 OAuth 2 的新版本以淘汰 OAuth 1.x，它强烈建议新的 Auth 提供者切换到 OAuth2。

OAuth 1.0a 修订版修复了 1.0 中发现的许多安全漏洞，被广泛认为是迄今为止最安全的 OAuth 版本。

OAuth2 是一个全新的协议，不向后兼容 OAuth 1.x。此thread 中列出了与 OAuth 1 相关的主要区别。

但是，并不是每个人都对新标准感到满意。 OAuth 规范的主要作者和编辑 Eran Hammer-Lahav 以blog post 中的原因从委员会辞职。

Homakov，因在 Github 上的功绩而一举成名，has not so nice things to say about OAuth 2。

所以是的，OAuth 2 已经正式取代了 OAuth 1.x，但是对于应该使用 OAuth2 还是坚持使用 OAuth 1.0a，网络上存在着相互矛盾的意见。

【讨论】：

作为一个有趣的附注，您可以阅读对 Eran 博客条目的反驳，这里：blogs.mnt.se/the-bitter-taste-of-good-intentions
已经阅读了一些反驳，但从来没有遇到过这个链接，所以谢谢你。对于它的价值，我选择了 Oauth2 而不是其他版本。
@anfab 阅读提供的链接，选择 2.0 似乎是一个奇怪的选择。是不是因为同时出现了参考实现？
有很多原因，包括客户端和服务器端实现的简单性。 Andre D 在下面的精彩评论也有一些原因为什么选择 Oauth2 而不是其他版本。

【解决方案2】：

是的）

大多数公司使用 2.0 - 例如google：

重要提示：OAuth 1.0 已于 4 月 20 日正式弃用， 2012 年。它将根据我们的弃用政策继续工作，但我们建议您尽快迁移到 OAuth 2.0。

但也有一些使用 1.0 或 1.0a，您可以在 OAuth 服务提供商列表

一章中看到 wiki: OAuth

还有官方信息说1.0已弃用RFC 6749: The OAuth 2.0 Authorization Framework

.. 本规范取代并废弃了 OAuth 1.0 RFC 5849 中描述的协议。

RFC 5849 是 The OAuth 1.0 Protocol

【讨论】：

@dan - 在您的链接中 OAuth 1.0 协议 我还没有找到 1.0 已被弃用的信息
在最上面写着“被淘汰：6749”——不是吗？

【解决方案3】：

您的问题的直接答案是是。来自OAuth 2.0 spec：

本规范的目的是新实现支持本文档中指定的 OAuth 2.0，并且 OAuth 1.0 仅用于支持现有部署。

虽然我更喜欢 OAuth 2.0，并且已经实现了 2.0 授权服务器并为规范做出了贡献，但我不能说一个比另一个更好。我确实相信 2.0 更易于使用。

作为一个有用的协议，OAuth 1.0 并没有过时或无关紧要。从 1.0a 版（RFC 5849 为 1.0a）开始，我知道没有任何漏洞会导致其安全性低于 2.0，事实上它可以说默认情况下更安全。 1.0 同样能够处理大多数用例。

OAuth 2.0 与 OAuth 1.0 不兼容；这是一个全新的协议。推动 2.0 开发的设计决策并非植根于 1.0 本身的缺陷，本身，而是 2.0 是出于使 OAuth 更易于实现、更优雅的用例的愿望对于 1.0 来说很难（例如原生应用）。

可能值得注意的一些差异：

2.0 依赖于 TLS 加密连接提供的安全性。 1.0 不需要 TLS，因此协议更加复杂，因为它必须包含自己的针对中间人攻击的防御。例如，1.0 依赖于signed requests 来访问受保护的资源，而 2.0 提供了一个非常更简单的Bearer 访问令牌类型。
2.0 将 OAuth 服务器拆分为两个conceptual roles：（1）授权服务器和（2）资源服务器。这种关注点分离自然适合授权关注点分布在负责不同类型资源的许多服务器的企业。
2.0 区分confidential and public clients。公共客户端是在用户设备上运行的客户端，因此它们不能可靠地保密（硬编码的嵌入式凭据）。区分机密客户端和公共客户端可以更轻松地做出满足客户端应用程序开发人员需求的安全实施决策。
2.0 引入了多个authorization grant types。每种授权类型都有自己的协议流，这些协议流使 OAuth 2.0 适用于多种用例和客户端类型。
2.0 在可扩展性方面做了很大的努力。 Section 8 of the spec 规定了定义新的访问令牌类型、授权类型和协议参数。例如，除了不记名令牌之外，MAC tokens 和 JWT bearer tokens 的工作也在进行中。

这是主观的，但有人可能会说 OAuth 2.0 试图在许多用例中保持灵活性，其中 OAuth 1.0 要求开发人员将他们的用例适应更严格的框架。

【讨论】：

【解决方案4】：

我真的不认为您可以说 OAuth 1.0 已被弃用，取而代之的是 OAuth 2.0。如果 1.0 符合您的要求，您仍然可以使用它。

2.0 更适合像 Twitter 这样的大规模使用，弃用并将其 API 从 1 更改为 1.1，以便使用新的 OAuth，但这与 twitter 有关。在另一种情况下，可能是 1.0。仍然可以完美运行，因此无需升级。

OAuth 2.0。必须更多地使用公共加密，公钥。而且不是私人的，也不是好消息，因为这种方法现在已经众所周知。所以这样是好是坏还是众说纷纭。

这里是Oauth2.0 and the road to hell，这里是OAuth 2.0'bad'，我想你可以找到更多有趣和详细的信息。

【讨论】：