授权是一个古老的概念，它是一个多用户系统必须支持的功能特性。比如，Alice和Bob都是Google的用户，那么Alice应该可以将自己的照片授权给Bob访问。但请注意到，这种授权是一种封闭授权，它只支持系统内部用户之间的相互授权，而不能支持与其他外部系统或用户之间的授权。比如说，Alice想使用“网易印像服务”将她的部分照片冲印出来，她怎么能做到呢？

肯定有人会说，Alice可以将自己的Google用户名和密码告诉网易印像服务，事情不就解决了吗？是的，但只有毫不关注安全和隐私的同学才会出此“绝招”。那么我们就来想一想，这一“绝招”存在哪些问题？

(1) 网易印像服务可能会缓存Alice的用户名和密码，而且可能没有加密保护。它一旦遭到攻击，Alice就会躺着中枪。

(2) 网易印像服务可以访问Alice在Google上的所有资源，Alice无法对他们进行最小的权限控制，比如只允许访问某一张照片，1小时内访问有效。

(3) Alice无法撤消她的单个授权，除非Alice更新密码。

上面的例子写的通俗易懂，各位一看就明白了，后面作者还附了一个这样图，以及注释：

从引言部分的描述我们可以看出，OAuth的参与实体至少有如下三个：

· RO (resourceowner): 资源所有者，对资源具有授权能力的人。如上文中的用户Alice。

· RS (resourceserver): 资源服务器，它存储资源，并处理对资源的访问请求。如Google资源服务器，它所保管的资源就是用户Alice的照片。

· Client: 第三方应用，它获得RO的授权后便可以去访问RO的资源。如网易印像服务。

此外，为了支持开放授权功能以及更好地描述开放授权协议，OAuth引入了第四个参与实体：

· AS(authorization server): 授权服务器，它认证RO的身份，为RO提供授权审批流程，并最终颁发授权令牌(Access Token)。读者请注意，为了便于协议的描述，这里只是在逻辑上把AS与RS区分开来；在物理上，AS与RS的功能可以由同一个服务器来提供服务。

如图1所示，协议的基本流程如下：

(1) Client请求RO的授权，请求中一般包含：要访问的资源路径，操作类型，Client的身份等信息。

(2) RO批准授权，并将“授权证据”发送给Client。至于RO如何批准，这个是协议之外的事情。典型的做法是，AS提供授权审批界面，让RO显式批准。这个可以参考下一节实例化分析中的描述。

(3) Client向AS请求“访问令牌(AccessToken)”。此时，Client需向AS提供RO的“授权证据”，以及Client自己身份的凭证。

(4) AS验证通过后，向Client返回“访问令牌”。访问令牌也有多种类型，若为bearer类型，那么谁持有访问令牌，谁就能访问资源。

(5) Client携带“访问令牌”访问RS上的资源。在令牌的有效期内，Client可以多次携带令牌去访问资源。

(6) RS验证令牌的有效性，比如是否伪造、是否越权、是否过期，验证通过后，才能提供服务。

虽然上面的例子举的很好，图画的也很清楚，可是对于我这种愚钝的人，还是理解了半天，请允许我在此狗尾续貂一次吧：

其实上面的图就如同这样一个故事

1、我的一个同事小张（Client），向我或者公司（RO）借钱，他会给我说：“借给我2000元，可以吗？”（也就是说向我请求一个有限的资源，就是Authorization Request）；

2、这时我肯定不会把我的银行卡给他，并告诉他密码，我要用到OAuth。首先我会说“好的”，并且给他写一个条，上面写着“允许小张借款2000元”的请求（Authorization Grant）；

3、小张拿着我写的条（AuthorizationGrant），给财务总监（AS）；

4、财务总监看到我的条后会给小张一个提款单（Access Token），上面写着请出纳给小张支出2000元的借款。

5、小张拿到了提款单（AccessToken）到出纳那里，按照公司的规定，出纳只有看到了财务总监给的提款单（Access Token），才能过支出钱，这是出纳核对后，小张就顺利的拿到了2000元钱（Protected Resource）。

根据上面的故事我们来说已说OAuth的特点：

1、小张不可能知道，我或者公司总共有多少钱；

2、我也保护了账户的密码，维护的公司的制度；

3、就像现实中一样，财务总监和出纳一般都在一起办公，而AS和RS一般也会在同一个服务器上；

4、按照同样的公司制度（也就是OAuth），其他人不管谁来支出钱都要这样，我只需要保证制度执行的严密，其他任何人都不会知道我的帐务信息了。

这也就是OAuth全称--- OpenAuthorization（开放式授权）的意义了。

下面我来看看为微信中是如何实现这个过程的，我引用了方倍工作室教程里面的图（http://www.cnblogs.com/txw1958/p/weixin71-oauth20.html）：

在这个途中User就是我例子中的小张，APP就是我，Auth_svr就是财务总监和出纳。

如果我使用微信中的官法提法因该这么说：

1、小张向我提出访问，访问过程涉及以下参数：

   也就是要知道我的APPID：其实就是我的名字；redirect_uri：到财务那里怎么走；response_type：知道我想我要批条（请填写code）；scope批条的类别（后面会介绍到）；state：到财务那里带些什么（参数）。

2、我同意了他的要求

  也就是微信帮助提到的“如果用户同意授权，页面将跳转至 redirect_uri/?code=CODE&state=STATE。”也就是我给了小张一个批条（code），告诉小张去财务的路，以及到那里需要带些什么。

3、小张拿着我的批条到财务总监那里得到提款单

小张拿着我的批条（code），按照“redirect_uri/?code=CODE&state=STATE”这个路径去财务那里“通过code换取网页授权access_token”

上图可以知道我还可以获得OPENID！这个是非常重要的，前一章提到了它的用处，微信在这里还特别强调了“获取用户基本信息接口是在用户和公众号产生消息交互时，才能根据用户OpenID获取用户基本信息，而网页授权的方式获取用户基本信息，则无需消息交互，只是用户进入到公众号的网页，就可弹出请求用户授权的界面，用户授权后，就可获得其基本信息（此过程甚至不需要用户已经关注公众号。）”

4、小张拿到了提款单又到出纳那里提款

得到了access_token后，拉取用户信息，也就是“通过access_token和openid拉取用户信息了。”

最终得到是如下的信息：

本来就此已经说完了，不过不少研发人员可能还是会有疑问：“费这么半天劲，不就得到了个用户的基本信息嘛，我通过其他方式也可以得到！”。

其实不然，这还是非常有用的：

第一，这是唯一一个重不需要关注你的微信好就可获得用户信息的办法；

第二，我们来设想一下下面场景：如果我们开发一个系统想过没想过不要用户名和密码了？用户登录，并授权以后，进入我们的系统，我系统里面存放着这个微信号（OPENID）对应的权限的功能。这样我再也不用担心用户忘记密码或者密码泄露的事情了，因为这些事情微信已经帮助给做了。说到这里可能你还会问：“那岂不是每个人必须有微信号”，我先不说这里我们做的就是微信平台的应用，也不说腾讯有多大的野心，这种OAuth协议已经在微博，google，baidu，邮箱等广泛应用，我做他们响应的接口，你就说一个上用你系统的人，没有微信还不能有微博，google，baidu这些帐号，没有这些帐号你还能没有个邮箱？这些我觉得因该是以后的趋势。

何况，随着微信的完善，以后或许我们拿到的不仅是用户的基本信息，还有用户朋友圈的帖子，图片，用户的喜好等等，这些都为我们新开发的系统提供了有效的可分析的数据！