限时领|《AI 百问百答》专栏课+实体书(包邮)! 了解详情
写点什么

OAuth 2.0 对 Web 有害吗?

  • 2010-09-24
  • 本文字数:2816 字

    阅读完需:约 9 分钟

在最近的五年间,复合应用程序已经从新奇的事物变成了主流。在构建复合应用程序时,关键的架构问题之一就是在访问特定服务的时候需要双重认证,以及相关的认证规则: 一般,我们需要对触发服务的(复合)应用程序和复合应用程序本身的用户进行认证,同时还要能够为应用程序和用户定义服务访问规则。这在客户端/ 服务器中间件环境中尤其困难,包括HTTP 环境,因为多年以来它们构建的前提就是“客户端”只会表现为单一的标识:或者是软件客户端,或者是用户,而不能二者都是。

现在典型的复合应用程序会使用流行的API(像Twitter、Facebook 或者Google),通过这些API 它会请求对用户特定的数据进行访问。之前,复合应用程序的开发者需要了解针对每项服务的用户证书,那样才能够访问他们的数据并以字母顺序的方式将它们混合在一起。Jeff Altwood 曾经用一种情况与这个过程做过比较,那种情况是和某人要房间的钥匙,目的只是要获得通讯簿。 2007 年四月,一小组人创建了 OAuth 项目,初始成员包括 Blaine Cook、Chris Messina、Larry Halff 和 David Recordon

OAuth 是位于 HTTP 和 HTTPS 上层的协议,它让复合应用程序和服务的用户都可以为服务和应用程序赋予部分访问权限。它基于第三方的信任联盟:用户 - 应用程序、用户 - 服务和应用程序 - 服务。 这个组织很快就发布了 OAuth 1.0 规范,人们也开始使用它。 OAuth 1.0 可能发布地太快了,因此广受批评。之后很快就出现了与之竞争的 WRAP(Web 资源授权协议),它很快地进行了标准化,成为OAuth 的对手。从那时开始,OAuth 工作小组就开始着手创建 OAuth 2.0

OAuth 最明显的便利性在于, Twitter 在本月(2010 年 9 月)决定对访问它的 API 实行强制认证,然后不再支持基本的认证方式。Michael Calore 解释说:

Twitter 的这个举措反映出在社会化网络的更广泛的趋势,其中当服务和应用程序与用户的账号连接的时候,基本的认证需要扩展为更安全的 OAuth。

包括iCodeBlog 在内的很多网站都提供了教程,帮助开发者快速地更新他们的应用程序。并且,即便OAuth 还处于草稿阶段,它已经得到了Facebook 的支持,它已经预定是OAuth 协议最大的实现者,并且是该规范的关键利益相关者。

看起来这次业界已经对解决这个重要的问题达成了广泛的共识。然而, OAuth 2.0 的一位制定者,同时也是 OAuth 早期的贡献者 Eran Hammer-Lahav 突然离开了这个工作组,并在离开之前发布了关于这个规范的最新方向的批评意见,认为规范因为“不记名的令牌(bearer tokens)”而放弃了数字签名和加密。然而,Eran 自己也承认,“加密是不可原谅的”。开发者很容易在对消息加密或者签名的步骤中犯错,并且一般这是不可原谅的错误。放弃加密是 WRAP 的初始想法的一部分:

在 WRAP 架构的核心有一种需求,就是要从客户端移除所有加密。WRAP 的作者发现,开发者因为 OAuth 1.0 中的数字签名而痛苦挣扎,他们的结论是,完全放弃数字签名是最好的解决方案。取而代之的是,他们决定依赖于已经得到验证的并且广泛可用的技术:HTTPS(或者更准确地说是 SSL/TLS)。如果开发者可以在他们的请求中添加一个字符(将 http:// 更改为 https://)就可以保护自己的秘密不被窃听者得到,为什么要使用数字签名呢?后续的批评大多是集中于 WRAP 并非真的需要 HTTPS 上。这只是提供了一种选择。 这种对没有秘密的令牌或者其它验证机制的使用被叫做不记名令牌(这与 cookie 类似)。所有持有令牌的人都会获得访问权限。如果你是攻击者,那么只需要持有这个简单的字符串,就可以来去自如。不需要任何数字签名、计算、反向工程,或者类似的方法。

这个模型的支持者的观点如下: 既然大多数服务都使用基于 cookie 的认证系统,那么使用额外的机制也不会更安全,因为攻击者总会把目标定在最脆弱的地方。实际上,Eran 的担心不是关于当前的 OAuth 的,而是关于这个规范将在五年之内所产生的影响,那时肯定会需要更安全的协议。首先,论点再次提到,由于 OAuth 2.0 是最脆弱的环节,就没有必要实现更强壮的安全机制。其次,OAuth 能够在当前的环境中工作的原因就在于,所有 API 都针对客户端做了很好的签名,并且大多数 API 终端都是在客户端代码或配置中静态声明的,在应用程序发布之前都得到了彻底的测试。因此总的来说,几乎没有将这个令牌发送到不友好的目标站点的风险。

《RESTful Web Services Cookbook》一书的作者 Subbu Allamaraju 在个人笔记中写到:

如果客户端应用程序向错误的地址发送请求(比方说“mail.exmple.org”而不是“mail.example.org”),位于“mail.exmple.com”恶意服务器就会得到客户端的访问令牌,并可以访问它的邮件。当然,对于浏览器的情况,浏览器开发者应该负责不要通过实现相同的原始策略而泄漏 cookie。OAuth2.0 客户端开发者也有同样的责任。

然而,Eran 还是认为 Web 应该更安全,那样才能够支持更加动态的情况,并且支持通过各种服务实现的标准 API 的世界:

一旦我们试图通过服务引入可发现或者互操作的 API,OAuth 2.0 就会出现故障。因为它缺少对令牌的加密保护(没有任何令牌秘密),客户端需要指出向哪里发送令牌才是安全的。OAuth 依赖于 cookie 模型来获得相同的解决方案——让客户端来应用安全策略,并指出和哪些服务器共享它的令牌。当然,资源服务器能够请求任何授权服务器所发布的令牌。例如,受保护的资源可以声称,它需要 Google 发布的 OAuth 访问令牌,事实上此时是与 Google 无关的(即便它可能是 Google 的子领域服务)。 客户端需要指出,服务器是否被授权能够看到它的 Google 访问令牌。Cookie 拥有关于哪个 cookie 与哪台服务器共享的规则。但是,因为这些规则是由客户端执行的,所以长久以来的问题是,对 cookie 的错误共享会产生安全性的故障。对于 OAuth 2.0 也是一样。

他做出这样的结论:

任何基于客户端执行安全策略的解决方案都会被打破,并出现故障。OAuth 1.0 通过支持数字签名来解决这个问题。如果客户端向错误的服务器发送了请求,什么危险的事情都不会发生,因为恶意服务器没有任何方法使用那个错误导向的请求来做任何事。如果客户端向错误的服务器(通过发现找到的)发送 OAuth 2.0 请求,那台服务器就可以自由访问用户的资源,因为令牌是有效的。
没有发现机制,较小的公司想要让他们的服务可以访问,需要花费大量的时间。

复合应用程序快速成为关键的变革方向,它为简单的数据——像任务、朋友或者 TV 指南——添加了新的价值。同时,OAuth 对快速地采用做出了平衡,因为它解决了严重的问题,并在业界得到了一些动力,比方说 Facebook 和 Twitter 对它的支持。 和经常在标准化过程中所发生的一样,我们现在处于十字路口,我们的业界需要选择这条路,或者是那条路:我们是要支持更简单的安全机制,从而让大量开发者能够创建这些复合应用程序呢?还是应该实现更强壮的机制,那会让其他开发者创建更多与现存的服务交互和竞争的服务呢?你站在哪一边呢?

查看英文原文: Is OAuth 2.0 Bad for the Web?

2010-09-24 06:589163
用户头像

发布了 340 篇内容, 共 139.5 次阅读, 收获喜欢 13 次。

关注

评论

发布
暂无评论
发现更多内容

什么是WebAssembly及其必要性

谐云

WebAssenbly

红队攻防之快速打点

权说安全

网络攻防

自动化回归测试平台 AREX 0.4.0 版本发布

AREX 中文社区

开源 自动化测试 接口测试

传统网络环境应付不了企业发展需求,华为云下载加速解决方案体验如何?

YG科技

基于eBPF技术的可观测实践探索

谐云

云原生

MySQL笔记之Checkpoint机制

互联网工科生

MySQL 高可用 CheckPoint

98位企业技术高管入学百度AICA 大模型带来AI人才三大能力要求

飞桨PaddlePaddle

人工智能 百度 paddle 百度飞桨

代码随想录训练营Day04 - 链表(下)

jjn0703

在 Go 中如何实现类似 Python 中的 with 上下文管理器

江湖十年

Go 后端

从低谷逆转,数字化转型企业可以信任华为云SparkPack

YG科技

WebAssembly:让Istio变得更强大

谐云

istio WebAssenbly

内卷时代如何上云,华为云Web及移动App上云又有何亮点?

YG科技

“科创中国”大湾区青年百人会论坛成功举办

飞桨PaddlePaddle

人工智能 百度 paddle 百度飞桨

代码随想录训练营Day03- 链表(上)

jjn0703

ChatGLM2-6B环境搭建

IT蜗壳-Tango

大厂月入3w+,失业焦虑折磨着我

程序员晚枫

程序员 大厂 焦虑

云原生MYSQL数据库架构分享

谐云

MySQL 云原生

华为云下载加速解决方案:让您的下载更快更稳定

YG科技

福昕软件与国广传媒达成战略合作,共促AI技术创新发展

新消费日报

什么是KubeEdge?

谐云

kuberedge kurbernetes

业财一体,精细管控丨华为云SparkPack助力成长型企业数字化转型

YG科技

浅谈kubernetes存储—glusterfs故障排查

谐云

kuberedge

微服务架构概览图

wiflish

微服务 微服务架构 架构治理

AI、机器学习、大模型、生成式AI和安全

啸天

人工智能 机器学习 安全 大模型 ChatGPT

华为云SparkPack:成长型企业的数字化转型利器

YG科技

IoTLink版本更新V1.34.0

山东云则信息科技

Java Vue 后端 物联网 前段

落地领域大模型应知必会 (1) :主要微调方法总览

Baihai IDP

人工智能 白海科技 大语言模型 大模型微调 领域大模型

基于多尺度图神经网络的流场预测,实现精度与速度的平衡

飞桨PaddlePaddle

人工智能 百度 paddle 飞桨 百度飞桨

OAuth 2.0对Web有害吗?_安全_Jean-Jacques Dubray_InfoQ精选文章