OAuth详解之一：动机

最近正在学习OAuth协议，看了《OAuth 2 in Action》这本书。本文是对该书第一章内容的小结。如果想看原汁原味的解读，请找这本书的原版读一读。第一章的核心内容就是在回答一个问题：为什么需要OAuth这个协议？

用一句话说，该协议提供了一种，在不欺骗资源拥有者的前提下，通过某种方式以资源拥有者的名义访问资源的方法。这种方式就是资源拥有者对访问者的 授权（authorization）。如图1.2（以下图片均来自该书）。

具体到应用场景，资源拥有者可以是一个有权访问和授权Web API的账户，而资源就是相应的Web API。资源访问者可以是API的使用者，比如一个浏览器。如果没有OAuth，那么浏览器需要拿到拥有者的认证信息，比如用户名、密码，session信息等，然后通过这个信息请求Web API的授权。如果资源和访问者在同一个安全域，上述方案比较容易实现，浏览器（访问者）只需要用当前登录用户（资源拥有者）的认证信息（以资源拥有者的名义）再去请求API（资源）即可。然而，如果API资源与访问者不在同一个域内，比如API由第三方提供，显然当前用户的的认证信息第三方资源是不认的，上述方案失效。这时访问者可以询问资源拥有者，你的新的认证信息是什么，比如用户（资源拥有者）需要告诉当前登录的浏览器（访问者），他在另一个服务（资源）的账号密码是什么。这样做的一个缺陷是，浏览器或者其他客户端为了持续访问资源，通常会保存服务的认证信息，一旦客户端遭到攻击，认证信息泄露，那么用户的资源就有危险，因此这是一个十分危险的行为。如图1.3。

以上两种方式有个共同点，就是客户端在扮演资源拥有者（登录用户）的角色（impersonating），资源在处理访问请求时，无法区分是 扮演者还是真正的 拥有者。为什么要做这个区分？就是为了 更细致的权限控制。授权的过程可以细化到允许某个访问者只读，而另一个访问者可以读写，甚至删除。如果不区分对所有访问着一视同仁，那么在上述场景中，攻击者可能对资源进行篡改和删除。另外，如果想终止授权，你只能改原来的登录密码。

还有一个方案，资源拥有者可以为各个客户端生成一个访问密码。这样虽然可以避免，拥有者将自己的登录密码共享，却需要额外维护这个访问密码，况且，访问密码与各个应用不是一一对应，如果要仅仅停止某个应用的授权无法做到。如图1.6。

基于上述讨论，我们需要的授权方案有一下特征：

1. 不需要共享资源拥有者的认证信息。
2. 针对特定客户端应用和资源拥有者生成一个新的凭据（credentials）用于资源访问（可以针对特定应用取消授权）。
3. 可以访问权限可以是受限的（如仅允许读操作）。
4. 实现某种协议来实现上述过程（如凭据的生成、分发）。

OAuth可以提供这样的方案。

在OAuth协议中，客户端作为资源拥有者的代理（delegate），访问受保护的资源。具体的过程如下，首先客户端向资源拥有者申请授权，就是想要成为这个访问代理。资源拥有者会到授权服务器上（authorization server 一个新角色）做认证，告诉授权服务器，资源是我的，我是可信任的。然后，资源拥有者可以选择是否授权给这个客户端，以及授予哪些权限给这个客户端，并告知授权服务器。客户端被授权后，就可以向授权服务器申请一个访问令牌（access token），拿到token后，就可以直接访问受保护的资源了。如图1.8。

注意，在这个过程中，资源拥有者的凭据并没有共享给任何客户端，因为它是直接到授权服务器做认证的，没有经过客户端。并且，一个有效的授权包含一个有效的资源拥有者（通过认证）信息、一个访问者信息以及要访问的资源信息，也就是说授权服务器需要明确的是， 把谁的资源的哪些访问权授予哪个访问者了。

在实际应用中，授权服务器和资源服务器可能合二为一，只是以不同形式的服务存在。一个用户在某个客户端登录Web站点后，就使用登录信息进行资源的授权，随后客户端就使用token对资源服务器发起请求。从安全的角度讲，OAuth将一些安全性工作转移到授权服务器，客户端需要做的是保护好session和token等信息，至于用户的登录凭据、以及授权过程都在服务器端实现，这是合理的，因为客户端可以是成千上万并且种类多样的。有一点需要注意，OAuth是一个授权（authorization）协议，并不是一个认证（authentication）协议，它需要知道 某个用户授予了某客户端某种访问权限，但不需要知道这个 用户具体是谁，也就是某个用户信息对它来说没有特别意义。虽然授权服务器上集成了认证模块，但也不能说OAuth是认证协议。

以上就是OAuth协议的基本思路，其中的每个步骤都有很详细的和多样化的实现，以满足不同需求，计划在后续文章详细解读。 

如有理解有误指出，欢迎指教。