我们首先来认识一下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验证令牌的有效性，比如是否伪造、是否越权、是否过期，验证通过后，才能提供服务。
虽然上面的例子举的很好，图画的也很清楚，可是对于我这种愚钝的人，还是理解了半天，请允许我在此狗尾续貂一次吧：
其实上面的图就如同这样一个故事
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这些帐号，没有这些帐号你还能没有个邮箱？这些我觉得因该是以后的趋势。
何况，随着微信的完善，以后或许我们拿到的不仅是用户的基本信息，还有用户朋友圈的帖子，图片，用户的喜好等等，这些都为我们新开发的系统提供了有效的可分析的数据！