1.5　OAuth 2.0不能做什么

OAuth被许多不同类型的API和应用使用，以前所未有的方式连接网络世界。即使已经无处不在，但OAuth并不是无所不能，明确它的能力范围对理解协议本身很重要。

由于OAuth被定义为一个框架，对于OAuth是什么和不是什么，一直未明确。鉴于此处的讨论目的以及本书的目的，我们所说的OAuth是指OAuth核心规范中定义的协议， 核心规范详述了一系列获取访问令牌的方法；还包括其伴随规范中定义的bearer令牌， 该规范规定了这种令牌的用法。获取令牌和使用令牌这两个环节是OAuth的基本要素。正如我们将在本节中看到的，在更广泛的OAuth生态系统中存在很多其他技术，它们配合OAuth核心，提供更多OAuth本身不能提供的功能。我们认为，这样的生态系统是协议健康发展的体现，但是不应与协议本身混为一谈。

OAuth没有定义HTTP协议之外的情形 。由于使用bearer令牌的OAuth 2.0并不提供消息签名，因此不应该脱离HTTPS（TLS上的HTTP）使用。机密信息需要在网络上传播，所以OAuth需要TLS这样的传输机制来保护这些信息。有一个标准定义了如何在简单认证与安全层（SASL）之上使用OAuth令牌。 也有在受限应用协议（CoAP）之上使用OAuth的新尝试。 未来还可能出现使OAuth的部分处理过程运行在非TLS链接之上的尝试（见第15章的讨论）。但即便如此，在使用其他协议和系统时，也需要有一个明确的机制来承担HTTPS事务所承担的任务。

OAuth不是身份认证协议 ，虽然可以用它构建一个。正如我们将在第13章深入讨论的那样，尽管用户确实存在，但OAuth事务本身并不透露关于用户的信息。想一想照片打印的例子：照片打印服务不需要知道用户是谁，只需要有人告诉它可以下载照片即可。OAuth本质上只是一个部件，能用于在更宏大的技术方案中提供其他功能。另外，OAuth在多个地方用到了身份认证，最典型的就是资源拥有者和客户端软件要向授权服务器进行身份认证。但这种内嵌身份认证的行为并不会使OAuth自身成为身份认证协议。

OAuth没有定义用户对用户的授权机制 ，尽管它在根本上是一个用户向软件授权的协议。OAuth假设资源拥有者能够控制客户端。要使资源拥有者向另一个用户授权，仅使用OAuth是不行的。但这种授权并不罕见，User Managed Access协议（将在第14章中讨论）就是为此而生，它规定了如何使用OAuth构建一个支持用户对用户授权的系统。

OAuth没有定义授权处理机制 ，OAuth提供了一种方法来传达授权委托已发生这一事实，但是它并不定义授权的内容。相反，由服务API定义使用权限范围、令牌之类的OAuth组件来定义一个给定的令牌适用于哪些操作。

OAuth没有定义令牌格式 。实际上，OAuth协议明确声明了令牌的内容对客户端是完全不透明的。这不同于之前的一些安全协议，如WS-*、安全断言标记语言（SAML）和Kerberos，这些协议都要求客户端应用能够解析并处理令牌。但是，颁发令牌的授权服务器和接收令牌的受保护资源仍然需要理解令牌。这个层面的互操作性要求催生了JSON Web Token （JWT）格式和令牌内省协议，这将在第11章讨论。虽然令牌本身对客户端还是不透明的，但现在它的格式能被其他组件理解。

OAuth 2.0没有定义加密方法 ，这与OAuth 1.0不同。OAuth 2.0没有定义新的加密机制，而是允许借用通用的加密机制，这些加密机制不止适用于OAuth。这种有意的遗漏催生了JSON对象签名和加密（JOSE）规范套件，该套件提供了一系列通用的加密机制，可以配合OAuth使用，也可以脱离OAuth使用。第11章将详细说明JOSE规范，第15章会将它用于一种消息级的加密协议，该协议使用了OAuth PoP令牌。

OAuth 2.0不是单体协议 。如前所述，该规范被分成了多个定义和流程，每个定义和流程都有各自适用的场景。在某种程度上，可以将OAuth 2.0视为一个安全协议生成器，因为它可用于为许多不同的应用场景设计安全架构。前一节中讨论过，这些系统并不一定要相互兼容。

OAuth无意用一个大而全的协议去解决安全系统所有方面的问题，而是只专注于一件事情，把剩下的问题留给其他组件，让它们各专所长。虽然还有很多议题不在OAuth范围之内，但它提供了一个坚实的基础，可以基于它构建其他更具针对性的工具，从而使安全架构设计更加完善。 MZg4gzpfnxVJoyS4cW/XHIf/JbkJ3ulD6v1omtQeBCy/f8tKwdtct01WdVd066bc