我们首先来认识一下OAuth协议吧，这个东西很早就听说过，总觉得离我很远（我的项目用不到这些），但是最近不得不学习一下了。我在网上找了一些解释，认为解释的最好的是这样说的（出处：http://hi.baidu.com/powerthinks/item/f1cb9b3c7a88251c9dc65efa）

如果你开车去酒店赴宴，你经常会苦于找不到停车位而耽误很多时间。是否有好办法可以避免这个问题呢？有的，听说有一些豪车的车主就不担心这个问题。豪车一般配备两种钥匙：主钥匙和泊车钥匙。当你到酒店后，只需要将泊车钥匙交给服务生，停车的事情就由服务生去处理。与主钥匙相比，这种泊车钥匙的使用功能是受限制的：它只能启动发动机并让车行驶一段有限的距离，可以锁车，但无法打开后备箱，无法使用车内其他设备。这里就体现了一种简单的“开放授权”思想：通过一把泊车钥匙，车主便能将汽车的部分使用功能（如启动发动机、行驶一段有限的距离）授权给服务生。

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

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

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

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

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

在以Web服务为核心的云计算时代，像用户Alice的这种授权需求变得日益迫切与兴盛，“开放授权(Open Authorization)”也正因此而生，意在帮助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显式批准。这个可以参考下一节实例化分析中的描述。<喎"http://www.2cto.com/kf/ware/vc/" target="_blank" class="keylink">vcD4KPHA+KDMpIENsaWVudM/yQVPH68fzobC3w87Kwe7FxihBY2Nlc3NUb2tlbimhsaGjtMvKsaOsQ2xpZW500OjP8kFTzOG5qVJPtcShsMrayKjWpL7dobGjrNLUvLBDbGllbnTX1Ly6ye233bXExr7WpKGjPC9wPgo8cD4oNCkgQVPR6dakzai5/brzo6zP8kNsaWVudLe1u9ihsLfDzsrB7sXGobGho7fDzsrB7sXG0rLT0Lbg1tbA4NDNo6zI9M6qYmVhcmVywODQzaOsxMfDtMuts9bT0LfDzsrB7sXGo6zLrb7NxNy3w87K18rUtKGjPC9wPgo8cD4oNSkgQ2xpZW500K+0+KGwt8POysHuxcahsbfDzspSU8nPtcTXytS0oaPU2sHuxca1xNPQ0KfG2sTao6xDbGllbnS/ydLUtuC0ztCvtPjB7sXGyKW3w87K18rUtKGjPC9wPgo8cD4oNikgUlPR6dakwe7FxrXE09DQp9DUo6yxyMjnyse38c6x1OyhosrHt/HUvciooaLKx7fxuf3G2qOs0enWpM2ouf2686OsssXE3Mzhuam3/s7xoaM8L3A+Cgo8cD4gPC9wPgoKPHA+y+TIu8nPw+a1xMD919O+2bXEuty6w6Oszby7rbXE0rK63Mfls/6jrL/Jyse21NPaztLV4tbW096227XEyMujrLu5ysfA7b3iwcuw68zso6zH69TK0O3O0tTatMu5t86y0Pj19dK7tM6wyaO6PC9wPgo8cD7G5Mq1yc/D5rXEzby+zcjnzazV4tH50ru49rnKysI8L3A+CjxwPjGhos7StcTSu7j2zazKwtCh1cWjqENsaWVudKOpo6zP8s7Su/LV37mry76jqFJPo6m96Meuo6zL+7vhuPjO0su1o7qhsL3ouPjO0jIwMDDUqqOsv8nS1MLwo7+hsaOo0rK+zcrHy7XP8s7Sx+vH89K7uPbT0M/etcTXytS0o6y+zcrHQXV0aG9yaXphdGlvbiBSZXF1ZXN0o6mjuzwvcD4KPHA+MqGi1eLKsc7Sv8+2qLK7u+Gw0c7StcTS+NDQv6i4+Mv7o6yyorjmy9/L+8PcwuujrM7S0qrTw7W9T0F1dGiho8rXz8jO0rvhy7WhsLrDtcShsaOssqLH0rj4y/vQtNK7uPbM9aOsyc/D5tC018WhsNTK0O3QodXFvei/7jIwMDDUqqGxtcTH68fzo6hBdXRob3JpemF0aW9uIEdyYW50o6mjuzwvcD4KPHA+M6Gi0KHVxcTD18XO0tC0tcTM9aOoQXV0aG9yaXphdGlvbkdyYW50o6mjrLj4ssbO8dfcvOCjqEFTo6mjuzwvcD4KPHA+NKGissbO8dfcvOC/tLW9ztK1xMz1uvO74bj40KHVxdK7uPbM4b/utaWjqEFjY2VzcyBUb2tlbqOpo6zJz8Pm0LTXxcfrs/bEybj40KHVxdans/YyMDAw1Kq1xL3ov+6hozwvcD4KPHA+NaGi0KHVxcTDtb3By8zhv+61paOoQWNjZXNzVG9rZW6jqbW9s/bEycTHwO+jrLC01dW5q8u+tcS55raoo6yz9sTJ1rvT0L+0tb3By7LGzvHX3LzguPi1xMzhv+61paOoQWNjZXNzIFRva2Vuo6mjrLLFxNy5/dans/bHrqOs1eLKx7P2xMm6y7bUuvOjrNCh1cW+zcuzwPu1xMTDtb3ByzIwMDDUqseuo6hQcm90ZWN0ZWQgUmVzb3VyY2WjqaGjPC9wPgo8cD4gPC9wPgo8cD64+b7dyc/D5rXEucrKws7Sw8fAtMu10tHLtU9BdXRotcTM2LXjo7o8L3A+CjxwPjGhotCh1cWyu7/JxNzWqrXAo6zO0rvy1d+5q8u+19y5stPQtuDJ2ceuo7s8L3A+CjxwPjKhos7S0rKxo7ukwcvVy7untcTD3MLro6zOrLuktcS5q8u+tcTWxrbIo7s8L3A+CjxwPjOhor7Nz/HP1sq11tDSu9H5o6yyxs7x19y84LrNs/bEydK7sOO2vNTa0rvG8LDsuaujrLb4QVO6zVJT0ruw49Kyu+HU2s2s0ru49rf+zvHG98nPo7s8L3A+CjxwPjShorC01dXNrNH5tcS5q8u+1sa2yKOo0rK+zcrHT0F1dGijqaOsxuTL+8jLsru53MutwLTWp7P2x662vNKq1eLR+aOsztLWu9Do0qqxo9ak1sa2yNa00NC1xNHPw9yjrMbky/vIzrrOyMu2vLK7u+HWqrXAztK1xNXKzvHQxc+iwcuhozwvcD4KPHA+1eLSsr7NysdPQXV0aMirs8YtLS0gT3BlbkF1dGhvcml6YXRpb26jqL+qt8XKvcrayKijqbXE0uLS5cHLoaM8L3A+CjxwPiA8L3A+CjxwPs/Cw+bO0sC0v7S/tM6qzqLQxdbQysfI57rOyrXP1tXiuPa5/bPMtcSjrM7S0v3Tw8HLt72xtrmk1/fK0r3Ms8zA78PmtcTNvKOoaHR0cDovL3d3dy5jbmJsb2dzLmNvbS90eHcxOTU4L3Avd2VpeGluNzEtb2F1dGgyMC5odG1so6mjujwvcD4KPHA+IDxpbWcgc3JjPQ=="http://www.2cto.com/uploadfile/Collfiles/20140812/20140306213649718.jpg" alt="\">

在这个途中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这些帐号，没有这些帐号你还能没有个邮箱？这些我觉得因该是以后的趋势。

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