微信公共服务平台开发(.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的功能可以由同一个服务器来提供服务。

 微信公共服务平台开发(.Net 的实现)12-------网页授权(上 :更加深入理解OAuth2.0 )_第1张图片

如图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):

 微信公共服务平台开发(.Net 的实现)12-------网页授权(上 :更加深入理解OAuth2.0 )_第2张图片

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

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

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

微信公共服务平台开发(.Net 的实现)12-------网页授权(上 :更加深入理解OAuth2.0 )_第3张图片

   也就是要知道我的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”

微信公共服务平台开发(.Net 的实现)12-------网页授权(上 :更加深入理解OAuth2.0 )_第4张图片

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

 

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

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

微信公共服务平台开发(.Net 的实现)12-------网页授权(上 :更加深入理解OAuth2.0 )_第5张图片

最终得到是如下的信息:

 微信公共服务平台开发(.Net 的实现)12-------网页授权(上 :更加深入理解OAuth2.0 )_第6张图片

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

其实不然,这还是非常有用的:

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

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

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

你可能感兴趣的:(.net,微信,OAuth)