微信公共服务平台开发（.Net 的实现）12-------网页受权（上 ：更加深刻理解OAuth2.0 ）

咱们首先来认识一下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显式批准。这个能够参考下一节实例化分析中的描述。

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

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

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

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

 

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

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

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

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

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

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

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

 

根据上面的故事咱们来讲已说OAuth的特色：

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

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

三、就像现实中同样，财务总监和出纳通常都在一块儿办公，而AS和RS通常也会在同一个服务器上；

四、按照一样的公司制度（也就是OAuth），其余人无论谁来支出钱都要这样，我只须要保证制度执行的严密，其余任何人都不会知道个人账务信息了。

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

 

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

 

 

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

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

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

 

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

 

二、我赞成了他的要求

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

 

三、小张拿着个人批条到财务总监那里获得提款单

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

 

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

 

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

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

 

最终获得是以下的信息：

 

 

原本就此已经说完了，不过很多研发人员可能仍是会有疑问：“费这么半天劲，不就获得了个用户的基本信息嘛，我经过其余方式也能够获得！”。

其实否则，这仍是很是有用的：

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

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

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