OAuth研究

一.OAuth protocol介绍

   An  open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.

  OAuth授权在各社交网站中广泛使用，该协议使用户不需要直接向第三方应用提供用户名及密码，并且使一个账户在多个网站中使用成为可能。

  OAuth协议中包含了三个角色：

  Service Provider，即服务提供者，如新浪微博

 User，即普通用户，如新浪微博用户

Consumer，即第三方应用，如本人开发的应用。

二.   三者之间原来的业务需求：User 想利用Consumer来更新自己在Service provider中的状态，常规的思想是：User可以将自己的username和password传递给Consumer，Consumer拿着User的username和password想Service Provider提出更新请求即可。但是由于涉及到第三应用Consumer，为了安全起见，User利用Consumer更新自己在Service Provider中的状态时，不能将自己的username和password传递给第三方应用Consumer，这种情况下，Service Provider并不信任Consumer，于是三者之间必须建立起信任关系。

  解决方案：Consumer首先向Service Provider 申请一对Consumer_Key和Consumer_Secret，以此取得Service Provider的信任。因为User是信任Service Provider，所以User与Consumer间的信任关系就依靠Service Provider建立了。Consumer用自己的Consumer_Key和Consumer_Secret向Service Provider请求到一对Request_Token和Request_Token_Secret，而后Consumer拿上这对RequestToken，领着User去见Service Provider。Service Provider见到自己发的RequestToken，便确认Consumer是值得信任的，于是把头转向User。如果Service Provider不记得User了，只要User想Service Provider提供username和password，就能建立起信任关系，然后Service Provider对User说：“我很信任这个Consumer，你是不是也要信任她？”若User确认，则Service Provider允许Consumer把User带回去，并发给Consumer一个Verifier。回来以后呀，Consumer拿着RequestToken和Verifier又单独去找Service Provider，取回来一对Access_Token和Access_Token_Secret，并长期保存。至此，三方信任关系就建立起来了，Consumer每次在Service Provider中更新User的状态时，只需要提供这对AccessToken，Service Provider便能确定此Consumer能代替User进行相应的操作。

OAuth进行开发时，所需要的关键字在上面场景中都有体现：Consumer_Key，Consumer_Secret，Request_Token，Request_Token_Secret，Verifier，Access_Token，Access_Token_Secret。

三.新浪微博开放平台OAuth授权接口

  oauth/request_token:consumer使用该接口向Service Provider索取RequestToken

 oauth/authorize:Consumer带上RequestToken，领着User，三者见面

oauth/access_Token：Consumer拿着Request_Token和Verifier，再次向Service Provider索取AccessToken

四.

具体每步执行信息如下：

A. 使用者（第三方软件）向OAUTH服务提供商请求未授权的RequestToken。向Request Token URL发起请求，请求需要带上的参数见上图。

B. OAUTH服务提供商同意使用者的请求，并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret，并返回给使用者。

C. 使用者向OAUTH服务提供商请求用户授权的RequestToken。向User Authorization URL发起请求，请求带上上步拿到的未授权的token与其密钥。

D. OAUTH服务提供商将引导用户授权。该过程可能会提示用户，你想将哪些受保护的资源授权给该应用。此步可能会返回授权的Request Token也可能不返回。如Yahoo OAUTH就不会返回任何信息给使用者。

E. Request Token 授权后，使用者将向Access Token URL发起请求，将上步授权的Request Token换取成Access Token。请求的参数见上图，这个比第一步A多了一个参数就是Request Token。

F. OAUTH服务提供商同意使用者的请求，并向其颁发Access Token与对应的密钥，并返回给使用者。

G. 使用者以后就可以使用上步返回的Access Token访问用户授权的资源。