前言

前言

我是Justin Richer,日常主要从事顾问工作,虽然假装自己是个安全怪咖,但我并不是科班出身。我的专业背景是协作技术,主要研究如何让人们借助计算机协同工作。即便如此,我也早就开始使用OAuth了。我用先前的OAuth 1.0实现了好几个服务器和客户端,将它们用在我当时开发的协作系统中。正是从那个时候我开始体会到,如果应用架构想要在真实环境中立于不败之地,那么一个优良的、易实施的、易用的安全系统便不可或缺。大约也是在那个时候,我参加了早期的Internet Identity Workshop会议。在会议上大家讨论了下一代OAuth,决定将OAuth 1.0在实际应用中的经验教训作为下一代OAuth的构建基础。在互联网工程任务组(IETF)开始开发OAuth 2.0时,我加入了这个小组并首次深度参与了讨论。几年之后,我们将规范制定了出来。虽然称不上完美,但它表现得很不错,人们对它青睐有加。

我一直留在OAuth工作组中,并担任了Dynamic Registration(RFC 7591和RFC 7592)和Token Introspection(RFC 7662)这两个OAuth扩展规范的编辑。如今,我是OAuth Proof of Possession(PoP)这一套规范的编辑以及其中某些部分的作者,还担任了多个OAuth配置规范(profile)、扩展以及相关协议的技术编辑。我还参与制定了OpenID Connect核心规范,并和我的团队一起实现了广受好评的MITREid Connect,它是基于OAuth和OpenID Connect的服务端与客户端套件。我突然发现,自己在向许多不同的受众谈论OAuth 2.0,并在各种各样的系统上实现它。我教过课,做过演讲,还写过一些关于OAuth 2.0的文章。

所以,当Antonio Sanso—— 一位受人尊敬的安全研究者——邀请我合著本书的时候,我们一拍即合。在搜寻了市面上有哪些关于OAuth 2.0的书之后,我们发现一本喜欢的都没有。我们找到的大部分书都是针对具体服务的,例如,如何写一个能和Facebook或Google交互的OAuth客户端,或者如何使用GitHub API对本地应用授权。如果你所关心的只是这方面的内容,那资料真是相当丰富。但我们没有看到有哪本书向读者介绍整个OAuth系统,解释其工作原理,指出其弱点、局限性以及优势。我们决定要以全方位的视角来写这样一本书,并且力求完美。因此,本书不会涉及任何与现实中特定OAuth服务商的交互,也不会详细讨论特定的API或行业领域。相反,本书的焦点在于OAuth本身的原理,希望让读者看到:当曲柄转动时,每一个齿轮是如何啮合的。

我们构建了一个代码框架,希望读者将注意力集中在OAuth的核心部分,而不要过度地陷入平台实现的细节。毕竟,这不是一本教读者“如何在最新的平台上实现OAuth”的书,而是想以本书“讲解OAuth 2.0的工作原理并让读者能在任何平台上使用它”。所以,我们基于Express.js构建了一个相对简易的Node.js框架。为了尽可能地消除平台特异性,我们大量使用了库。尽管如此,JavaScript还是JavaScript,有些特异之处仍然会不时出现,任何平台都会这样。但我们希望,读者能将本书所用的方法和理论应用到自己所喜爱的语言、平台和架构中去。

回顾历史,我们是如何走到现在的?故事开始于2006年,当时包括Twitter和Ma.Gnolia在内的很多Web服务公司,都有很多应用是互通的,他们希望能让用户将这些应用统一地连接起来。当时,此类连接都是通过在远程服务器上向用户索要凭据并将凭据传送到API上来实现的。然而,为方便登录,这些网站都使用了一项分布式身份认证技术——OpenID。这就导致无法将用户名和密码用于API。

为了解决这个问题,开发人员试图发明一个协议,允许用户将API访问授权出去。新的协议基于多个具有同样思想的专有实现,包括Google的AuthSub以及Yahoo!的BBAuth。在这些实现中,客户端应用只要获得用户的授权并得到一个令牌,就能使用这个令牌访问远程API。这些令牌的发放都包含公共和私有的部分,并且该协议使用了一种新型的(现在看来是脆弱的)加密签名机制,使得它可以在非TLS HTTP连接上使用。他们称这个协议为OAuth 1.0,并将其作为一项Web开放标准发布。它很快就获得响应,出现了多种语言对这一标准的自由实现。这一标准表现优秀,深受开发人员喜爱,甚至一些大型互联网公司也很快弃用了自己的专有机制,起初正是这些专有机制启发了OAuth。

和许多新的安全协议一样,OAuth 1.0在早期就被发现有一个缺陷。为了修复这个会话固化漏洞,OAuth 1.0a诞生了。这个版本后来作为RFC 5849被编入了IETF。在那个时候,OAuth协议的社区开始成长,新的用例被开发和实现。其中一些用例将OAuth用在了其原本并未有意适用的场景,但这些对OAuth的非常规使用也比现有的其他可用方案表现得更好。然而,OAuth 1.0只是一个单体协议,意图以不变应万变,用同一种机制来应对所有场景,在有些场景下使用它是有风险的。

RFC 5849发布后不久,Web Resource Access Protocol(WRAP)就发布了。这份协议采用了OAuth 1.0a的核心——客户端、委托、令牌——并对它们进行了扩展,以适应不同的需求。WRAP废除了OAuth 1.0中很多令人困惑和容易出问题的部分,比如自定义签名算法机制。经过社区的多次讨论,WRAP被确定为新的OAuth 2.0协议的基础。OAuth 1.0是单体的,而OAuth 2.0是模块化的。OAuth 2.0的模块化使其成为了一个框架,能够部署和运用在OAuth 1.0已经实践过的所有场景中,但并不会让协议的核心内容发生扭曲。本质上来说,OAuth 2.0在基础层面提供了设计规范。

2012年,IETF批准了OAuth 2.0核心规范,但是留给社区的工作还远未完成。规范被模块化地分成互补的两个部分:RFC 6749详细说明了如何获取令牌,RFC 6750则详细说明了如何在受保护的资源上使用一种特定类型的令牌(bearer令牌)。另外,RFC 6749的核心部分还详细阐明了多种获取令牌的方式,并提供了一种扩展机制。OAuth 2.0定义了4种许可类型,分别适用于不同的应用类型,而不是单单定义一种复杂的方法来适应不同的部署模型。

如今,OAuth 2.0已经是互联网上首选的授权协议。它被广泛使用,从大型互联网公司到小型创业公司,几乎所有的地方都在使用它。由基于OAuth 2.0构建的扩展、配置规范和完整协议组成的生态系统已经出现,人们也不断探索出对这一基础技术更多新颖、有趣的应用方式。本书的目标是帮助读者不仅理解OAuth 2.0是什么以及它的工作原理,而且还要知道如何以最佳的方式来用它解决问题、构建系统。

Justin Richer

目录

  • 版权声明
  • 前言
  • 致谢
  • 关于本书
  • 关于封面图片
  • 第一部分 起步
  • 第 1 章 OAuth 2.0是什么,为什么要关心它
  • 第 2 章 OAuth之舞
  • 第二部分 构建OAuth环境
  • 第 3 章 构建简单的OAuth客户端
  • 第 4 章 构建简单的OAuth受保护资源
  • 第 5 章 构建简单的OAuth授权服务器
  • 第 6 章 现实世界中的OAuth 2.0
  • 第三部分 OAuth 2.0 的实现与漏洞
  • 第 7 章 常见的客户端漏洞
  • 第 8 章 常见的受保护资源漏洞
  • 第 9 章 常见的授权服务器漏洞
  • 第 10 章 常见的OAuth令牌漏洞
  • 第四部分 更进一步
  • 第 11 章 OAuth令牌
  • 第 12 章 动态客户端注册
  • 第 13 章 将OAuth 2.0用于用户身份认证
  • 第 14 章 使用OAuth 2.0的协议和配置规范
  • 第 15 章 bearer令牌以外的选择
  • 第 16 章 归纳总结
  • 附录 A 代码框架介绍
  • 附录 B 补充代码清单