浅谈oauth

OAuth到处都在用，任何一样东西火爆无非有两点：

1. 炒作

2. 确实好用

OAuth两者皆有，总之，现在fb, tw, weibo, renren,到处都是oauth. 最近工作中也做了套OAuth服务器，还是记个笔记

首先OAuth是一个协议，是一个协议哦，亲，任何人都可以实现这个协议的服务器端和客户端，所以有这样的Oauth包，那样的Oauth包，java包，python包，javascript包，c/c++/c#/c####/cdefgb 包，包包晃眼

其次现在Oauth有1.0和2.0版本，不要以为2.0就好用，在我们实际项目中，就采用1.0， 2.0号称是更大更强更碉堡，但实际上，也更复杂更臃肿更累赘，OAuth协议的创立元老就为了这个2.0，一怒之下退出Oauth小组，所以没什么必要的话，去你妹的2.0吧

推荐两个连接，都讲得清楚透彻

http://hueniverse.com/oauth/guide/

http://tools.ietf.org/html/rfc5849

Oauth工作流程：

http://hueniverse.com/oauth/guide/workflow/

看这个吧，比较简单，一个东东产生了，必然有它的原因和需求，这里讲一下OAuth诞生主要为了解决的问题。在这个多元化的世界，人们越来越懒啦，以前人们要办点什么事，比如说买台电脑，直接提着现金到现场去，三摸两检查，就直接提货回家。现在呢，你懂的，我们有网购哦，有淘宝哦，有京东哦，亲，坐在家里，轻点鼠标，小卡一刷，直接送货上门，大门不出，新鲜电脑提回家，剩下的时间可以Dota, 可以YY， 作为一个ACG宅主，为什么要出门？有妹纸的包妹纸，没妹纸的多废纸，总而言之，很多事情不需要我们去做了，这个世间出了一个很奇怪的角色，叫经纪人，broker, or Agent, 以前叫跑腿，或者叫托

Oauth的出现，就是为了协调三者关系的，宅男，厂家，和跑腿，专业的说法叫：User, Service Provider and Consumer

 我们以链接的内容来举例，有一个服务提供商叫专存图片.com，专门负责供存放图片，有一天比如说某屌丝A，我们的主人公某日闲的无聊，自拍剪刀手嘟嘟嘴三张，存放在该专存图片.com上，这屌丝无聊就算了，他还想炫耀，于是就想把这些图片打印出来，理论上，把这些图片当下来，拷贝到U盘，找一个打印店打印就OK。 但是我们的屌丝很忙，忙着跟苍老师学书法，于是就网上去搜索跑腿. 果断让他给搜索出来一个，叫专打图片.com. 

屌丝：”你，去，把爷放在专存图片.com的靓照给打印出来“。

专打图片.com：”好啊好啊，把你用户名和密码给我”

屌丝：“用户名和密码都给你？“， ”我难道会告诉你，我的用户名是屌丝9527，密码是123456么？难道我会说，我拍的苍老师的照片都在那上面不能让你知道么？”， “万万不行”

专打图片.com无奈之下，只好去试试运气，找到了专存图片.com

专打图片.com:"嗨“

专存图片.com："嗨你妹，你是谁，从哪儿来，要去干什么？"

专打图片.com："某说哲学问题，我只是一跑腿，帮某屌丝，不知名，不知姓，来求取剪刀手嘟嘟嘴图片三张"

专存图片.com：“不知名不知姓还来？”，“跑你妹，打你妹，滚”

专打图片.com无可奈克，只好回复屌丝A:

专打图片.com：“没招，对方不知名不知姓不给图片“

屌丝：”这就是专业跑腿么？这点小问题都搞不定“， ”跑你妹，打你妹，滚”

=

在Oauth出现之前，这个专打图片.com就犯难了，这可怎么搞？如此二逼青年，又要干活，又不给用户名和密码，伤不起啊伤不起，势必只有破产一条路

但是，上帝说，要有光，于是就有了光，这个专打图片.com灵光一动，想到了一个高人，这个高人当初用电话机010101敲啊敲，愣是敲出了一个windows98， 如今隐居在米国，这个高人面临的问题用一句话来概述就是：

”一个屌丝想找一个跑腿去帮忙取一样东西但是该跑腿无凭无据请问如何能够成功取到该屌丝的东西？“

高人果然是高人，面授精囊妙计三张，专打图片.com就马上有谱了，于是重新去找屌丝A和服务提供商

先找到专存图片.com， 先递上红包一打，:"哥，我又来了，总说跑你妹打你妹也不是办法，现在的二逼青年那么多，都在用你服务，你不让我取照片，以后他们也不会在你这儿寸照片，咋俩合作吧”

专存图片.com一听有些道理，看在红包的份上，说:"好吧，你在我这儿留个名片，有事好商量”

专打图片.com又找到屌丝A：“哥，我又来了，我已经摆平专存图片.com，没问题了，以后有啥需求找我啊”

从此，他们三个人都过上了幸福愉快的生活。

究竟这个高人是传授的锦囊是啥呢，能让一个二逼屌丝，一个苦逼跑腿，和一个牛逼服务提供商相处甚欢，那就是我们的OAuth了，我们来看一看在高人的妙计下，他们是如何快乐的生活的吧:

屌丝：”你，去，把爷放在专存图片.com的靓照给打印出来“。

专打图片.com：”好啊好啊，我马上去”

专打图片.找到了专存图片.com的跑腿接待部门

专打图片.com:"嗨“

专存图片.com："嗨你妹，你是谁，从哪儿来，要去干什么？"

专打图片.com："我是跑腿9527， 跑腿号1388， 来帮某屌丝求取剪刀手嘟嘟嘴图片三张"

专存图片.com："跑腿9527， 跑腿号1388，嗯，确有此腿，准了，叫那屌丝打电话给屌丝确认部门，好了我call你，留个电话"

专打图片.com: "好呢，我电话15211118888“.

专打图片.com回复屌丝:

专打图片.com：“您老请好，对面需要你打电话给屌丝确认部门核对下身份，这是他们电话，请拨13888888888“

屌丝于是拨通了该电话

专存图片.com的屌丝确认部门:”你好，请报上身份和屌丝号“

屌丝A:"我是屌丝9527， 屌丝号123456”

专存图片.com的屌丝确认部门：“刚才有个跑腿9527想取你的图片，请确认允许”

屌丝A:"允许“

专存图片.com就call专打图片.com

专存图片.com：“跑腿跑腿，屌丝已确认，允许你进行操作，该屌丝临时代号为3188，请速度到许可领取部门来取屌丝许可证号"

专打图片.com于是就去找专存图片.com许可领取部门:

专打图片.com："你好，这是跑腿9527，跑腿号1388， 来领取屌丝临时代号为3188的许可证”

专存图片.com许可领取部门："这是许可证747474“

如今万事俱备，专存图片就可以利用该跑腿号，和屌丝临时代号，屌丝许可证去领取图片了

专存图片.com:"你好，我是跑腿9527， 跑腿号1388， 来取屌丝临时代号为3188的图片，这是屌丝许可证747474”

专存图片.com:"确认无误，剪刀手嘟嘟嘴图片三张，请查收”

专打图片.com于是就打印出来，返回给正在刻苦练习书法的屌丝：“你老请好，相片已打印，请付钱吧”

屌丝：“干得好，信用卡拿去，随便刷“

--------------------------------------------------------------------------------无敌华丽黄金分割线-----------------------------------------------------------------------------------------------

以上扯淡那么多，描述了OAuth的一个工作流程，在一个Oauth系统中，涉及到三个角色：User(屌丝）， Consumer(跑腿),  Service Provider(霸气服务提供商)

User是Service Provider的用户，存放有一定的资源在Service Provider处

Consumer是第三方程序，希望获取该User的资源，需要User的许可

OAuth的工作过程就是一个许可Consumer获取User资源的过程，并且不接触到User的任何私密验证信息（用户名，密码等）

在OAuth中，Service Provider，也就是服务器方，需要提供三个API：

Temporary Credential Request（跑腿验证部门）
         https://****/initiate

   Resource Owner Authorization URI:（屌丝确认部门）
         https://****/authorize

   Token Request URI:（许可领取部门）
         https://****/token

其作用也很明确，对于跑腿验证部门，就是验证consumer的身份，consumer往往需要在服务方注册等级过，获取一个跑腿ID和跑腿号：Consumer Key and Consumer Secret

对于屌丝确认部门，就是验证User身份，并且获取User的许可，这一步是由Service Provider来执行，Consumer完全不知情，一般需要访问service provider的验证页面，或者利用service provider封装的模块构造UI，供用户输入信息验证

对于许可领取部门，就是验证完了之后，Consumer领取User信息的API， 包括屌丝临时代号和屌丝许可证，Access Token and Access Secret

于是，用专业的话讲就是，Service provider 提供三个API， initiate, authorize, token. 

Consumer预先在Service provider处注册，获取Consumer key and comsumer secret

一笔事务的流程大致如下：

1. Consumer 先访问initate API, 提供Consumer key and comsumer secret， 验证consumer身份， 为下一步做准备

2. 跑腿验证成功，Consumer跳专到authorize API, 让Service provider开始对User进行验证，Consumer同时预留一个callback URL,供后续Service Provider 访问

3. 屌丝验证成功后，Service调用该callback URL 返回验证消息，用一个oauth_verifier来表示该验证结果

4. Consumer利用oauth_verifier（一般是一串字符，可以理解为ID），向provider获取Access Token 和Access Secret

6. 在接下来的每一笔请求里，带上Consumer key, comsumer secrete, Access Token ,Access Secret信息就O了

肿么样，大概还清楚吧，以上是三条腿的OAuth验证流程，其他还有些出于安全新的考虑，比如说加密，比如说timestamp, nonce等等，都比较简单，其中有一点比较重要， Secret是不会和请求一起传递的，Consumer key 和Acces Token是会和请求 一起传递，然后两个Secret会用做签名的密码，比如利用HMAC-SHA1算法，生成一段签名，在服务器端，根据请求内容和密码，也生成一段签名进行比较，若两个签名想同，则说明Secret无误

另外还有两条腿的OAuth验证流程(2-legged)，在这其中，Consumer和User是同一个角色，流程大大简化，OAuth也只是起到一个安全验证的作用了