Oauth简介

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。同时，任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的。

二、OAUTH简介
    在官方网站的首页，可以看到下面这段简介：
    An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.

    大概意思是说OAUTH是一种开放的协议，为桌面程序或者基于BS的web应用提供了一种简单的，标准的方式去访问需要用户授权的API服务。OAUTH类似于Flickr Auth、Google's AuthSub、Yahoo's BBAuth、 Facebook Auth等。OAUTH认证授权具有以下特点：
1. 简单：不管是OAUTH服务提供者还是应用开发者，都很容易于理解与使用；
2. 安全：没有涉及到用户密钥等信息，更安全更灵活；
3. 开放：任何服务提供商都可以实现OAUTH，任何软件开发商都可以使用OAUTH；

三、OAUTH相关术语
    在弄清楚OAUTH流程之前，我们先了解下OAUTH的一些术语的定义：
OAUTH相关的三个URL：
Request Token URL: 获取未授权的Request Token服务地址；
User Authorization URL: 获取用户授权的Request Token服务地址；
Access Token URL: 用授权的Request Token换取Access Token的服务地址；

OAUTH相关的参数定义：
oauth_consumer_key: 使用者的ID，OAUTH服务的直接使用者是开发者开发出来的应用。所以该参数值的获取一般是要去OAUTH服务提供商处注册一个应用，再获取该应用的oauth_consumer_key。如Yahoo该值的注册地址为：https://developer.yahoo.com/dashboard/
oauth_consumer_secret：oauth_consumer_key对应的密钥。
oauth_signature_method: 请求串的签名方法，应用每次向OAUTH三个服务地址发送请求时，必须对请求进行签名。签名的方法有：HMAC-SHA1、RSA-SHA1与PLAINTEXT等三种。
oauth_signature: 用上面的签名方法对请求的签名。
oauth_timestamp: 发起请求的时间戳，其值是距1970 00:00:00 GMT的秒数，必须是大于0的整数。本次请求的时间戳必须大于或者等于上次的时间戳。
oauth_nonce: 随机生成的字符串，用于防止请求的重放，防止外界的非法攻击。
oauth_version: OAUTH的版本号，可选，其值必须为1.0。

  OAUTH HTTP响应代码：
HTTP 400 Bad Request 请求错误
Unsupported parameter 参数错误
Unsupported signature method 签名方法错误
Missing required parameter 参数丢失
Duplicated OAuth Protocol Parameter 参数重复
HTTP 401 Unauthorized 未授权
Invalid Consumer Key 非法key
Invalid / expired Token 失效或者非法的token
Invalid signature 签名非法
Invalid / used nonce 非法的nonce

四、OAUTH认证授权流程
    在弄清楚了OAUTH的术语后，我们可以对OAUTH认证授权的流程进行初步认识。其实，简单的来说，OAUTH认证授权就三个步骤，三句话可以概括：
1. 获取未授权的Request Token
2. 获取用户授权的Request Token
3. 用授权的Request Token换取Access Token

    当应用拿到Access Token后，就可以有权访问用户授权的资源了。大家肯能看出来了，这三个步骤不就是对应OAUTH的三个URL服务地址嘛。一点没错，上面的三个步骤中，每个步骤分别请求一个URL，并且收到相关信息，并且拿到上步的相关信息去请求接下来的URL直到拿到Access Token。具体的步骤如下图所示：

具体每步执行信息如下：
A. 使用者（第三方软件）向OAUTH服务提供商请求未授权的Request Token。向Request Token URL发起请求，请求需要带上的参数见上图。

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

C. 使用者向OAUTH服务提供商请求用户授权的Request Token。向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访问用户授权的资源。

以上步骤说的是oauth1.0，OAuth1.0定义了三种角色：User、Service Provider、Consumer。如何理解？假设我们做了一个SNS，它有一个功能，可以让会员把他们在Google上的联系人导入到SNS上，那么此时的会员是User，Google是Service Providere，而SNS则是Consumer。

1 oauth1.0对手机客户端，移动设备等非server第三方的支持不好。其实oauth1.0也是可以支持手机客户端，移动设备等，也有相应的流程。但是oauth1.0是将多种流程合并成了一种，而事实证明，这种合并的流程体验性非常差
2 oauth1.0的三步认证过程比较繁琐和复杂，对第三方开发者增加了极大的开发难度
3 oauth1.0的加密需求过于复杂，第三方开发者使用oauth之前需要花费精力先实现oauth1.0的加密算法
4 oauth1.0的拓展性不够好
5 oauth1.0生成的access_token要求是永久有效的，这导致的问题是网站的安全性和破坏网站的架构
 
因此出现了oauth2.0
 
oauth2.0针对1.0的各种问题提供了解决方法：
1 oauth2.0提出了多种流程，各个客户端按照实际情况选择不同的流程来获取access_token。这样就解决了对移动设备等第三方的支持，也解决了拓展性的问题
2 oauth2.0删除了繁琐的加密算法。利用了https传输对认证的安全性进行了保证
3 oauth2.0的认证流程一般只有2步，对开发者来说，减轻了负担
4 oauth2.0提出了access_token的更新方案，获取access_token的同时也获取refresh_token, access_token是有过期时间的，refresh_token的过期时间较长，这样能随时使用refresh_token对access_token进行更新。
在详细说明授权流程之前，我们需要先了解一下OAuth2.0中的角色：
OAuth1.0定义了三种角色：User、Service Provider、Consumer。而OAuth2.0则定义了四种角色：Resource Owner、Resource Server、Client、Authorization Server：
Resource Owner：User
Resource Server：Service Provider
Client：Consumer
Authorization Server：Service Provider
也就是说，OAuth2.0把原本OAuth1.0里的Service Provider角色分拆成Resource Server和Authorization Server两个角色，在授权时交互的是Authorization Server，在请求资源时交互的是Resource Server，当然，有时候他们是合二为一的。

Web Server Flow：
web ServerFlow是把oauth1.0的三个步骤缩略为两个步骤
 
首先这个是适合有server的第三方使用的。
1客户端http请求authorize
2服务端接收到authorize请求，返回用户登陆框页面
3用户在客户端登陆
4服务器端将浏览器定位到callbackurl，并同时传递Authorization Code
5客户端使用https发送access_token
6服务器端收到access_token请求，验证Authorization Code---生成access_token, refresh_token,和过期时间--access_token和refresh_token和过期时间入库
7 返回access_token和refresh_token,过期时间
8 用户使用HTTPS+ access_token请求开放平台接口
 
User-Agent:
适合所有无server端配合的客户端
1客户端http请求authorize
2服务端接收到authorize请求，返回用户登陆框页面
3用户在客户端登陆
4服务器端将浏览器定位到callbackurl，并同时传递access_token和过期时间
 
这里面的access_token可以考虑放在缓存中而不是放在数据库中，一旦过期时间到就可以作废了
 
Username and Password Flow
适合所有情况
1 客户端https请求access_token（使用https是由于参数中带着开心网的用户名和密码信息）2 服务器端收到access_token请求---生成access_token, refresh_token,和过期时间--access_token和refresh_token和过期时间入库
3 json返回access_token, refresh_token,和过期时间

 
这里面的access_token可以考虑放在缓存中而不是放在数据库中，一旦过期时间到就可以作废了

国内的很多的社交都有开放接口，新浪微博，人人，qq等。现在一般都是同过webview来进行处理。

参考：http://blog.csdn.net/hereweare2009/article/details/3968582

http://www.cnblogs.com/yjf512/archive/2011/08/31/2161259.html