1.1　OAuth 2.0是什么

OAuth 2.0是一个授权协议，它允许软件应用代表（而不是充当）资源拥有者去访问资源拥有者的资源。应用向资源拥有者请求授权，然后取得 令牌 （token），并用它来访问资源。这一切都不需要应用去充当资源拥有者的身份，因为令牌明确表示了被授予的访问权。从很多方面来说，你可以把OAuth令牌看作Web上的“泊车钥匙”。不是所有车都有泊车钥匙，但是对于有泊车钥匙的车来说，把泊车钥匙交给泊车员比直接交出常规钥匙更安全。泊车钥匙限制泊车员只能操作点火开关和车门，而不能打开后备箱和手套箱。更高级的泊车钥匙还能限制最高车速，甚至能在车辆行使超过车主设定的距离后强制停车并向车主发出警报。同样的道理，OAuth令牌可以限制客户端只能执行资源拥有者授权的操作。

举个例子，假设你使用了一个照片云存储服务和一个云打印服务，并且想使用云打印服务来打印存放在云存储服务上的照片。很幸运，这两个服务能够使用API来通信。这很好，但两个服务由不同的公司提供，这意味着你在云存储服务上的账户和在云打印服务上的账户没有关联。使用OAuth可以解决这个问题：授权云打印服务访问照片，但并不需要将存储服务上的账户密码交给它。

虽然OAuth基本上不关心它所保护的资源类型，但它确实很适合当今的RESTful Web服务，也适用于Web应用和原生应用。从小型单用户应用，到有数百万用户的互联网API，它都适用。在受控的企业环境中，它能对新一代内部业务API和系统访问进行管理，在它所成长起来的纷乱复杂的Web环境中，它也能游刃有余地保护各种面向用户的API。

而这还不是全部：如果你在过去5年内使用过移动应用或者Web应用，很可能已经使用过OAuth来授权应用。实际上，不管有没有意识到，只要你见过如图1-1所示的页面，那就使用过OAuth。

在一般情况下，OAuth协议是不会被用户觉察到的，例如Steam和Spotify的桌面应用。除非主动地去探寻OAuth的痕迹，否则用户永远不会知道他使用了OAuth。 这是很好的特性，因为优秀的安全系统在一切功能都正常时就应该不被觉察。

众所周知，OAuth是一个安全协议，但是它到底有什么用途呢？既然你捧起了一本关于OAuth 2.0的书，那么问这个问题理所当然。协议规范 是这样定义的：

稍微解释一下：作为一个 授权框架 ，OAuth关注的是如何让一个系统组件获取对另一个系统组件的访问权限。在OAuth的世界中，最常见的情形是客户端应用代表资源拥有者（通常是最终用户）访问受保护资源。到目前为止，我们需要关心如下组件。

• 资源拥有者 有权访问API，并能将API访问权限委托出去。资源拥有者一般是能使用浏览器的人。因此，本书在插图中将资源拥有者表示为一个坐在浏览器前的人。
• 受保护资源 是资源拥有者有权限访问的组件。这样的组件有多种形式，但大多数情况下是某种形式的Web API。虽然“资源”听起来就像是某种能下载的东西，但其实这些API支持读、写和其他操作。本书在插图中将受保护资源表示为带有锁图标的机架式服务器。
• 客户端 是代表资源拥有者访问受保护资源的软件。如果你是Web开发人员，“客户端”这个名称会让你觉得它是指浏览器，但它在本书中并不是这个意思。如果你是商业应用开发人员，可能以为“客户端”是指付费使用服务的客户， 但这也不是它的正确含义。在OAuth中，只要软件使用了受保护资源上的API，它就是客户端。每当本书提到“客户端”一词时，几乎都是特指该含义。本书插图中将客户端绘制成带有齿轮的计算机屏幕。由于实际存在的客户端应用类型有多种（如第6章所述），因此没有一个图标能普遍适用。

第2章将更深入地探讨这些细节。但现在，你要知道整个系统的目标是：让客户端为资源拥有者访问受保护资源（如图1-2所示）。

在照片打印的例子中，假设你将度假时拍的照片上传到了照片存储网站，现在想要将它们打印出来。照片存储网站的API就是资源，打印服务则是那个API的客户端。作为资源拥有者，你需要将一部分权力委托给照片打印服务，让它能读取你的照片。但你可能不想让打印服务读取所有的照片，也不想让它有删除或者上传照片的权限。总之，你的目的就是打印你指定的照片。如果你和大多数用户一样，那么可能并不会去思考：怎样的安全架构才能实现这一目标。

值得庆幸的是，由于你正在阅读本书，因此应该和大多数用户不一样，会很关注安全架构。下一节会展示在不使用OAuth的情况下，如何以不那么完美的方式解决这个问题，然后再展示如何使用OAuth更好地解决这个问题。 s16e6nEFsiqFz/T2zv5yVEIT2B0wu1UmB1mhDW+0mUf6C6V1/YIV4qsCGEUAbYZ3