来搞一记Oauth吧

那些简单的故事，就别用复杂的方式传诵

##【让我来讲几个故事吧】

从前，有只老兔子，在仓库里存了一万根胡萝卜，作为给小兔子的遗产。而后他就去周游世界了。小兔子有天想去把萝卜拿出来，却被仓库外的一只兔子拦住了。一问才知道，这是老兔子安排的仓库守卫。和所有故事中的守护者一样，他正直而古板，八字眉下面有着睡眠不足的熊猫眼，世人一般称他为兔门神。兔子想要拿到萝卜，就得说服兔门神呀，于是他走了上前…

##【兔子与OAuth1.0的故事】

  1. 兔子首先得证明自己是只兔子，不是狗熊也不是狼，于是他向兔门神出示了身份证
  2. 兔门神说：哦，你是只兔子。但你还得证明你是老兔子的兔崽子呀。兔子说我爸旅游去了，怎么证明呢？兔门神说，这样吧，我把你的身份证拍下来，发送给你爸，让他看下这是不是你。于是兔门神打开了微信……
  3. 正在休假的老兔子看了下照片，回复说证件照好难看毁三观啊，但勉强认得出这货就是我儿子
  4. 兔门神确认这信息后，说，你老爸还是认你这个儿子的
  5. 兔子问，那我可以去拿胡萝卜了没？
  6. 兔门神说，可以了，这样吧，我发你个通行证，以后拿这个来我就不用这么麻烦了。

##【兔子与OAuth1.0a的故事】

这种貌似天衣无缝的形式，却被一只坏兔子看出了破绽。他注意到一个细节，在最后的一步，兔门神都是习惯性的把通行证交给了面前的兔子,而不管这只兔子是不是当初的那只。于是，坏兔子趁兔门神正在和老兔子聊微信的时候，一个劲站在了兔子前面，最后兔门神居然把通行证塞给了他！这怎么可以？于是在第一步和第六步又有了修改。

  1. 兔子出示身份证的同时，也出示了自己的私房照，说，门神大哥呀，后面你记得把通行证给照片上的帅哥！
  2. ……
  3. ……
  4. ……
  5. ……
  6. 兔门神看了下面前的兔子，私房照上的明显P过嘛但勉强认得出是本人，于是才交出了通行证

##【兔子与Oauth2.0的故事】

兔门神回家后，向他的老婆兔女神汇报了今天的工作，更安全的方案使他得意洋洋，没想到被兔女神骂了一顿。兔女神说，兔子证明自己还得带个身份证，你不知道在天朝办个身份证多麻烦吗？让小兔子跟老兔子去聊下微信就可以了干嘛要你插手？兔门神哑口无言，兔女神高贵冷艳的说我有四种方案，给你先说说最常用的一种吧。

  1. 兔子一开始就跟他老爸聊微信了。当然他得明确告诉老爸，他需要打开哪个仓库（因为老兔子有很多儿子，每个儿子去拿萝卜的仓库不一样，兔子要指定一下具体是哪个，问他可不可以）
  2. 老兔子回复说：“just do IT”…
  3. 兔子然后去拿胡萝卜，首先被兔女神拦住了。女神告诉他，你要给我四样东西：老兔子的回复，你的私房照，身份证，还要给我一个密码。兔子愣愣的想了个密码，把这四样东西交了过去
  4. 兔女神把这四种东西混在一起，用魔法变出了两件法宝：一封情书和一撮猴子毛…然后她解释说：拿着我的情书去找我老公，他就让你进仓库了；但是这情书会过期，是出于安全考虑啦，过期后你得召唤我再写一封，召唤出我的步骤就是吹一下猴子毛，像孙悟空那样你就别在意这些细节好伐？
  5. 兔子拿着情书去找兔门神时，发现他由于被妻子分担了压力，明显睡眠好多了…

##【演员表】

兔子-消费者，也就是第三方应用
老兔子-用户，也就是我们，记住，我们永远是第三方的亲爹
仓库-Oauth提供者，这里有我们保存的资料，比如说新浪微博，qq空间，人人…
兔门神-在前两个故事中，由授权服务器和资源服务器共同扮演，在最后的故事中，只由资源服务器扮演
兔女神-授权服务器，只管授权，不管取资源

##【重要道具】

身份证-签名，将一个http请求以及相应参数字符串化
拍下的身份证照片-Request Token，服务器进行认证
通行证-Access Token，获取资源的凭证
私房照-重定向地址
坏兔子(我把它当成道具而不是演员)-重定向地址劫持
仓库的名称-appId,即对应具体哪个第三方
just do it-Auth code，用户授权号
第三个故事的身份证-client id 客户端帐号
密码-client secret 客户端密码
魔法-将client id，client secket，重定向地址，Auth code生成Access Token
情书-Access Token，获取资源的凭证
猴子毛-Refresh Token，用来在Access Token过期后将其刷新，刷新需带上client id和client secret
##【说书人说】

Oauth2.0比起Oauth1.0，没有了第一步的签名，将服务器分开为授权服务器与资源服务器。这是最大的两个特征。开放平台必须得做到对第三方友好，才有利于接入。像Oauth1.0签名的操作，就难倒了许多第三方。也许你知道了Oauth2.0接入步骤简化了些，但也知道其内部实现要更复杂，抛去安全方面的考虑，我认为这是正确的方向。因为，Oauth2.0在某种意义上说，向第三方做到了——“把悲伤留给自己，你的美丽让你带走”。