我正在互联网上寻找关于这方面的一些信息,最后是关于The Oauth 1.0协议的RFC :http://tools.ietf.org/html/rfc5849
您可以在其顶部阅读"已废弃:6749",如果您按照该链接进行操作,则最终会使用OAuth 2.0授权框架 RFC.
基于此,我是否可以安全地推断OAuth 1.0已被弃用以支持OAuth 2.0?
谢谢.
anf*_*fab 22
是和否.
IETF发布了OAuth 2的新版本,淘汰了OAuth 1.x,强烈建议新的Auth提供商切换到OAuth2.
对OAuth 1.0a进行了修订,修复了1.0中发现的许多安全漏洞,并被广泛认为是最安全的OAuth版本.
OAuth2是一个全新的协议,并不向后兼容OAuth 1.x. 此线程中列出了与OAuth 1相关的主要差异.
然而,并非所有人都对新标准感到满意.OAuth规范的主要作者和编辑Eran Hammer-Lahav在此博客文章中引用了委员会的理由而辞职.
Homakov凭借对Github的攻击而声名鹊起,对于OAuth 2并没有那么好的说法.
所以,是的,OAuth 2正式取代了OAuth 1.x,但网上是否应该使用OAuth2或坚持OAuth 1.0a存在相互矛盾的意见.
是的)
大多数公司使用2.0 - 例如谷歌:
重要提示:截至2012年4月20日,OAuth 1.0已正式弃用.它将继续按照我们的弃用政策运行,但我们建议您尽快迁移到OAuth 2.0.
但有一些使用1.0或1.0a,因为你可以在OAuth服务提供商列表一章中看到wiki:OAuth
还有一个官方信息,不推荐使用RFC RFC 6749:OAuth 2.0授权框架
..此规范取代并废弃了RFC 5849中描述的OAuth 1.0协议.
RFC 5849是OAuth 1.0协议
您的问题的直接答案是肯定的。从OAuth 2.0 规范:
本规范的意图是新实现支持本文档中指定的 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 依赖签名请求来访问受保护资源,而 2.0 提供了更简单的Bearer访问令牌类型。
2.0 将 OAuth 服务器拆分为两个概念角色:(1) 授权服务器和 (2) 资源服务器。这种关注点分离自然适合企业,其中授权关注点分布在负责不同类型资源的许多服务器上。
2.0 区分机密客户端和公共客户端。公共客户端是在用户设备上运行的客户端,因此它们无法可靠地保密(硬编码的嵌入式凭据)。区分机密客户端和公共客户端可以更轻松地做出适合客户端应用程序开发人员需求的安全实施决策。
2.0 引入了多种授权授予类型。每种授权类型都有自己的协议流,这些协议流使 OAuth 2.0 能够适应多种用例和客户端类型。
2.0 为可扩展做出了巨大努力。规范的第 8 节规定了定义新的访问令牌类型、授权类型和协议参数。例如,除了不记名令牌之外,工作还涉及MAC 令牌和JWT 不记名令牌。
这是主观的,但有人可能会说 OAuth 2.0 试图为许多用例提供灵活性,其中 OAuth 1.0 要求开发人员将他们的用例纳入更严格的框架中。
归档时间: |
|
查看次数: |
4133 次 |
最近记录: |