思维导图
前言
OAuth 2.0定义了4种许可类型，分别适用于不同的应用类型，而不是单单定义一种复杂的方法来适应不同的部署模型
OAuth 2.0已经是互联网上首选的授权协议。它被广泛使用，从大型互联网公司到小型创业公司，几乎所有的地方都在使用它。
第 1 章 OAuth 2.0是什么，为什么要关心它
OAuth是一个安全协议，用于保护全球范围内大量且在不断增长的Web API
用于连接不同的网站，还支持原生应用和移动应用与云服务之间的连接。它是各领域标准协议中的安全层
1.1 OAuth 2.0是什么
OAuth 2.0是一个授权协议，它允许软件应用代表（而不是充当）资源拥有者去访问资源拥有者的资源。应用向资源拥有者请求授权，然后取得令牌（token），并用它来访问资源。这一切都不需要应用去充当资源拥有者的身份，因为令牌明确表示了被授予的访问权。
OAuth 2.0框架能让第三方应用以有限的权限访问HTTP服务，可以通过构建资源拥有者与HTTP服务间的许可交互机制，让第三方应用代表资源拥有者访问服务，或者通过授予权限给第三方应用，让其代表自己访问服务。
作为一个授权框架，OAuth关注的是如何让一个系统组件获取对另一个系统组件的访问权限
需要关心如下组件
- 资源拥有者有权访问API，并能将API访问权限委托出去
- 受保护资源是资源拥有者有权限访问的组件
- 客户端是代表资源拥有者访问受保护资源的软件
- 整个系统的目标是：让客户端为资源拥有者访问受保护资源
图 1-2 代表资源拥有者连接客户端
1.3 授权访问
OAuth协议的设计目的是：让最终用户通过OAuth将他们在受保护资源上的部分权限委托给客户端应用，使客户端应用代表他们执行操作。
为实现这一点，OAuth在系统中引入了另外一个组件：授权服务器
图 1-7 OAuth授权服务器自动发送服务专用的密码
受保护资源依赖授权服务器向客户端颁发专用的安全凭据——OAuth访问令牌
客户端首先将资源拥有者引导至授权服务器，请求资源拥有者为其授权
然后一般会让资源拥有者选择是否对客户端授权
一旦授权请求被许可，客户端就可以向授权服务器请求访问令牌。按照资源拥有者的许可，客户端可以使用该令牌对受保护资源上的API进行访问
图 1-8 完整的OAuth工作过程
OAuth系统常遵循TOFU原则：首次使用时信任（trust on first use）。在TOFU模型中，需要用户在第一次运行时进行安全决策，而且并不为安全决策预设任何先决条件或者配置，仅提示用户做出决策。这个过程可以简单到只是询问用户“要连接到新的应用吗”
因为要求用户在一个上下文环境中做出安全决策具有很强的灵活性，而不断地要求用户做决策会让人疲倦，TOFU方法在这两者间实现了良好的平衡
如果用上TOFU方法，就可以在上述的两个名单中间增加一个灰名单，在这个名单中，会优先考虑用户在运行时做出的信任决策。会有一定的策略来记录和审查这些用户决策，以使风险最小化。通过灰名单功能，系统的可扩展性得到了极大提升，同时又不牺牲安全性。
1.4 OAuth 2.0：优点、缺点和丑陋的方面
OAuth 2.0的设计中有一个重要的假设，就是不受控的客户端总是比授权服务器或者受保护资源多出好几个数量级
OAuth令牌提供了一种比密码略复杂的机制，但如果使用得当，其安全性要比密码高很多。
图 1-10 OAuth生态系统中各组件的相对数量
1.5 OAuth 2.0不能做什么
由于OAuth被定义为一个框架
核心规范详述了一系列获取访问令牌的方法；还包括其伴随规范中定义的bearer令牌
该规范规定了这种令牌的用法。获取令牌和使用令牌这两个环节是OAuth的基本要素
OAuth没有定义HTTP协议之外的情
OAuth没有定义用户对用户的授权机制
要使资源拥有者向另一个用户授权，仅使用OAuth是不行的。但这种授权并不罕见，User Managed Access协议（将在第14章中讨论）就是为此而生，它规定了如何使用OAuth构建一个支持用户对用户授权的系统。
OAuth没有定义令牌格式。实际上，OAuth协议明确声明了令牌的内容对客户端是完全不透明的。
令牌的授权服务器和接收令牌的受保护资源仍然需要理解令牌。这个层面的互操作性要求催生了JSON Web Token （JWT）格式和令牌内省协议，这将在第11章讨论。虽然令牌本身对客户端还是不透明的，但现在它的格式能被其他组件理解。
OAuth无意用一个大而全的协议去解决安全系统所有方面的问题，而是只专注于一件事情，把剩下的问题留给其他组件，让它们各专所长。虽然还有很多议题不在OAuth范围之内，但它提供了一个坚实的基础，可以基于它构建其他更具针对性的工具，从而使安全架构设计更加完善。
1.6 小结
Auth是一个应用广泛的安全标准，它提供了一种安全访问受保护资源的方式，特别适用于Web API
2.1 OAuth 2.0协议概览：获取和使用令牌
Auth事务中的两个重要步骤是颁发令牌和使用令牌。令牌表示授予客户端的访问权，它在OAuth 2.0的各个部分都起到核心作用。
一个规范的OAuth事务包含以下事件
（1） 资源拥有者向客户端表示他希望客户端代表他执行一些任务（例如“从该服务下载我的照片，我想把它们打印出来”）
（2） 客户端在授权服务器上向资源拥有者请求授权
（3） 资源拥有者许可客户端的授权请求。
（4） 客户端接收到来自授权服务器的令牌。
（5） 客户端向受保护资源出示令牌
2.2 OAuth 2.0授权许可的完整过程
授权码许可中用到了一个临时凭据——授权码——来表示资源拥有者同意向客户端授权，如图2-1所示。
图 2-1 授权码许可的详细过程
为了最大限度地保持灵活性，OAuth协议去除了真实API系统的很多细节。具体来说，OAuth没有规定客户端如何知悉与受保护资源交互的方式，或者客户端如何发现受保护资源对应的授权服务器。这些问题一般都由建立在OAuth之上的其他协议以标准方式解决，例如OpenID Connect和User Managed Access（UMA）
当客户端发现需要获取一个新的OAuth访问令牌时，它会将资源拥有者重定向至授权服务器，并附带一个授权请求，表示它要向资源拥有者请求一些权限（如图2-2所示）。例如，为了能读取照片，照片打印服务可以向照片存储服务请求访问权限
图 2-2 将资源拥有者引导至授权服务器以启动授权流程
然后，授权服务器会要求用户进行身份认证。这一步对确认资源拥有者的身份以及能向客户端授予哪些权限来说至关重要
图 2-3 资源拥有者登录
因为资源拥有者通过浏览器与授权端点交互，所以也要通过浏览器来完成身份认证。因此，有很多身份认证技术可以用于用户身份认证流程。OAuth没有规定应该使用哪种身份认证技术，授权服务器可以自由选择，例如用户名/密码、加密证书、安全令牌、联合单点登录或者其他方式
授权服务器可以允许用户拒绝一部分或者全部权限范围，也可以让用户批准或者拒绝整个授权请求
图 2-4 资源拥有者批准客户端的授权请求
图 2-5 将授权码发送给客户端
这一步采用HTTP重定向的方式，回到客户端的redirect_uri。 HTTP 302 Found Location: http://localhost:9000/oauth_callback?code=8V1pr0rJ&state=Lwt50DDQKUB8U7jtfLQCVGDL9cnmwHH1 这又会导致浏览器向客户端发出如下请求。 GET /callback?code=8V1pr0rJ&state=Lwt50DDQKUB8U7jtfLQCVGDL9cnmwHH1 HTTP/1.1 Host: localhost:9000
由于使用的是授权码许可类型，因此该重定向链接中包含一个特殊的查询参数code。这个参数的值被称为授权码，它是一次性的凭据，表示用户授权决策的结果。客户端会在接收到请求之后解析该参数以获取授权码，并在下一步使用该授权码。客户端还会检查state参数值是否与它在前一个步骤中发送的值匹配
现在客户端已经得到授权码，它可以将其发送给授权服务器的令牌端点
图 2-6 客户端将授权码和自己的凭据发送给授权服务器
- 授权服务器接收该请求，如果请求有效，则颁发令牌（如图2-7所示）。授权服务器需要执行多个步骤以确保请求是合法的
图 2-7 客户端接收访问令牌
OAuth核心规范对bearer令牌的使用做了规定，无论是谁，只要持有bearer令牌就有权使用它。除非特别注明，本书中所有的示例都使用bearer令牌。bearer令牌具有特殊的安全属性
有了令牌，客户端就可以在访问受保护资源时出示令牌
客户端出示令牌的方式有多种，本例中将使用备受推荐的方式：使用Authorization头部。
受保护资源可以从头部中解析出令牌，判断它是否有效，从中得知授权者是谁以及授权内容，然后返回响应
2.4 OAuth的组件：令牌、权限范围和授权许可
Auth刷新令牌在概念上与访问令牌很相似，它也是由授权服务器颁发给客户端的令牌，客户端也不知道或不关心该令牌的内容。但不同的是，该令牌从来不会被发送给受保护资源。相反，客户端使用刷新令牌向授权服务器请求新的访问令牌，而不需要用户参与
刷新令牌还可以让客户端缩小它的权限范围。如果客户端被授予A、B、C三个权限范围，但是它知道某特定请求只需要A权限范围，则它可以使用刷新令牌重新获取一个仅包含A权限范围的访问令牌。这让足够智能的客户端可以遵循最小权限安全原则
