03. 人生若只如初见：在 OAuth 2 世界里的四种角色

世界级软件开发大师 Robert Martin 在其著作《敏捷软件开发：原则、实践与模式》和《架构整洁之道》两本书中首次提出和阐述了 SOLID 原则，其中最重要的一条原则就是单一职责原则（Single Responsibility Priciple，SRP），它指的是一个类或者模块只负责完成一个职责或功能（A class or module should hava a single responsibility）。OAuth 2 作为一个框架，它遵循了 SOLID 原则，设计了四个职责单一明确的角色，它们 OAuth流中各司其职。下面我为你依次介绍这些角色。

SOLID原则实际上是五个设计原则首字母的缩写，它们分别是单一职责原则（Single responsibility
principle，SRP、开放封闭原则（Open–closed principle，OCP）、Liskov 替换原则（Liskov
substitution principle，LSP）、接口隔离原则（Interface segregation
principle，ISP）、依赖倒置原则（Dependency inversion
principle，DIP）。如果你对这些设计原则有兴趣可以阅读我上面提到的两本书，此外许多关于面向对象和设计模式的书一般也会对这五个原则进行描述。

在介绍 OAuth 2 的四种角色之前，为了更加方便你理解这四种角色，让我沿用我在上一小节提到的“抖音助手”的故事场景。你所在的公司是一家专注于拍摄短视频的公司，你是负责运营的同学，很快又到了一周一次向老板报告过去一周业绩的日子。这些繁琐的数据收集和数据分析的过程让你每一周都头疼万分。你偶然发现有一个“抖音助手”的第三方软件，它可以帮你收集和分析你的视频和粉丝等数据，做一些数据分析并最终输出一份漂亮的报告。下图展示了这个联合工作的过程。

让我用文字描述一下上图所述的过程：

1. 你访问抖音助手，想让抖音助手帮助你分析过去七天的抖音视频数据。
2. 巧妇难为无米之炊，为了输出这份报告，它必须先从抖音获取到你的视频数据，用 OAuth 2 的行话说是它必须先得到一个代表用户授权信息的访问令牌，然后用这个访问令牌去换取你“托管”在抖音上的视频数据。因此它将你重定向到抖音。
3. 如果你没有登录，抖音将要求你进行登录，否则抖音将向你展示授权页面。
4. 你发现抖音助手除了申请获得视频的基础数据，它还想要获得粉丝画像数据，你做出了授权决策，粉丝数据是比较敏感的数据，你不允许它能获得这些数据。因此你拒绝了抖音助手获得粉丝画像数据的请求。
5. 抖音助手从抖音得到了一个访问令牌。
6. 抖音助手携带访问令牌向抖音 Open API 发出请求，要求获得对应的数据。它只能用这个访问令牌拉取视频的基础数据以及点赞、评论、播放分等享数据，但是抖音 Open API 保证它不能获取你的粉丝数据。
   上面这个故事场景描述了 OAuth2 四种角色联合工作的过程，它包含了 OAuth 2 规约的四种角色。

资源所有者（resource owner）

资源所有者即我们上述故事场景所描述的“抖音用户”。见文知意，资源所有者就是拥有资源的人（实体）。在OAuth 2 文档中进行了更一般化的描述——能够授予对受保护资源的访问权限的实体（An entity capable of granting access to a protected resource）。当该实体是人时（在客户端模式下实体是客户端对象），我们一般用终端用户来称呼该实体。我们在后文将延续和使用该名词。

资源服务器（resource server）

资源服务器，即我们上述故事场景描述的“抖音 OpenAPI”，它承载了抖音的开放 API。更通俗地说资源服务器是用来托管受保护资源的服务器。资源一般是数据或者服务，它们通常以 Restful API 的形式对外提供服务，这些 API 往往是受保护的资源，第三方应用程序必须持有和携带一个访问令牌来获取这些资源，除了托管资源，资源服务器还负责处理接受和响应来自客户端的资源调用请求，如上图中的第（6）步所示，资源服务器必须能够校验访问令牌的有效性和合法性，只有携带正确访问令牌的请求资源服务器才会向其响应资源。

客户端（client）

客户端即我们上述所说的“抖音助手”，客户端即代表终端用户访问用户资源的应用程序。在授权码模式下客户端需要发出授权请求，引导用户去授权服务器获得授权许可。在获得用户的授权许可后客户端需要发出令牌请求以交换访问令牌。如果客户端和授权服务器属于同一组织或者机构，我们可以将这种应用称为第一方应用。如果客户端和授权服务器属于不同的组织或者机构，我们可以将这种应用称为第三方应用。例如上面所述的抖音助手和抖音都归属于字节跳动旗下，那么我们可以称这种应用为第一方应用。如果抖音助手是其它公司注册的应用，那么我们可以称它为第三方应用。第一方应用可能享有某些特权，比如管理员可以直接通过手动的方式给第一方应用配置客户端凭证信息而不用经过复杂繁琐的客户端注册过程。但是不管是一个客户端是第一方应用还是第三方应用在 OAuth 2中它们的含义和作用都一模一样，客户端时开发者不应该对这两种形式客户端应用产生疑惑。

一个客户端应用程序可以是网站或移动应用程序，甚至是一个纯粹由JavaScript书写的单页面应用程序，OAuth 2为此将其划分为不同的客户端类型，你将在下一小节获得客户端的所有细节。

授权服务器（authorization server）

授权服务器是OAuth中最重要和复杂的角色。它连接了资源拥有者和客户端以及资源服务器角色。回顾一下上面我描述的抖音助手的故事场景，授权服务器处在绝对中心的位置。它的主要任务是向客户端应用程序颁发代表终端用户访问资源的访问令牌。

1. 授权服务器需要管理客户端信息并有能力认证客户端。在某些授权模式下（例如授权码模式），授权服务器还需要管理和认证终端用户的身份信息。
2. 客户端需要与授权服务器进行对话，以获得授权服务器生成和颁发的访问令牌。
3. 终端用户需要与授权服务器进行对话。在 OAuth 2 的某些授权模式下（例如授权码模式下），授权服务器需要认证当前终端用户的身份，否则直接向终端用户展示授权页面。授权服务器还需要接受终端用户的授权结果，并做出对应的响应。
4. 资源服务器需要与授权服务器对话，以验证资源请求中携带的访问令牌的有效性。

让我们再次回顾我在开篇词里授权服务器的端点图，我们看到授权服务器处在绝对中心的位置，它需要与不同的角色进行交互，承担复杂的功能。授权服务器也是我们小册的重点，我在小册的第二关将会手把手带你实现一个生产可用的完全遵循OAuth 2.0规范的授权服务器。