写点什么

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:588886
用户头像

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

关注

评论

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

为什么全球顶尖银行纷纷选择与华为合作?

脑极体

AI

校园跑腿小程序前端零基础带你开发一款属于自己的校园跑腿小程序 同城跑腿代办小程序开发学习代取快递代买东西代寄快递含骑手端管理员端用户端 校园圈子论坛

多客潇潇

【中文汉化版】W10 Digital Activation win10激活工具 win11激活

理理

云开发让 Unity 微信小游戏实时聊起来

蛋先生DX

腾讯云 Unity 云开发 实时聊天 微信小游戏

docker和podman的区别

百度搜索:蓝易云

(全新升级AlDente - 电荷限制器) AlDente Pro for mac v1.28.2 兼容macos15系统

理理

Rhinoceros 8破解版 犀牛8中文直装版【Mac&win】

理理

我一进门就看见 AI 在啪啪啪狂敲代码

江南一点雨

天猫商品详情数据API接口:解锁高效数据获取的钥匙

代码忍者

API 接口 pinduoduo API

面试官:单核服务器可以不加锁吗?

王磊

架构设计的悖论,复用是美好的还是邪恶的

阿里技术

阿里巴巴 中台 Supercell 代码复用 DRY原则

Things3 3.21.1 中文直装版 mac任务管理器

理理

程序逆向反汇编修改神器:IDA Pro/x64dbg

理理

人工智能(大模型)工程师中级课程,正式开始报名!

雅菲奥朗

人工智能 AI AIGC 人工智能工程师 人工智能工程师培训

Linux中的comm命令及示例

百度搜索:蓝易云

Zabbix 2024 中国峰会在上海举办,Databuff 携最业界领先研发成果重磅亮相

乘云数字DataBuff

故障定位 zabbix 峰会

鸿蒙NEXT生态应用核心技术理念:统一生态,原生智能

芯盾时代

鸿蒙 生态

TinkerTool System 9 for mac苹果电脑系统设置和维护工具 支持苹果mac15系统

理理

FinOps三人行:共话FinOps云成本管理与AI的未来在线分享(文字+视频)

雅菲奥朗

FinOps AIGC 云成本管理 云财务管理 FinOps认证

Java音视频文件解析工具

江南一点雨

Docker实战:docker compose搭建Rocketmq

百度搜索:蓝易云

小间距显示屏方案的具体要求

Dylan

应用 LED LED display LED显示屏 效果广告

macos苹果电脑深度清理卸载工具App Cleaner & Uninstaller 完美兼容苹果Sequoia 15系统

理理

概念回顾:现代应用架构中的数据平面、管理平面和控制平面

NGINX开源社区

读书笔记 开源 个人成长

Pixologic ZBrush 2024下载 附ZBrush 2024破解补丁 三维数字雕刻

理理

TablePlus for Mac/win (本地原生数据开发软件)v6.0.0激活版

理理

ROS 编程入门的介绍

梦笔生花

ROS

linux下可用的清理工具BleachBit

百度搜索:蓝易云

C基础-操作符详解

百度搜索:蓝易云

VMware NSX Advanced Load Balancer (NSX ALB) 22.1.7 发布下载,新增功能概览

sysin

负载均衡 Lab nsx

【Tomcat源码分析】启动过程深度解析 (二)

派大星

tomcat源码解读

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