OAuth2的介绍

OAuth2 诞生背景

在传统的客户端-服务端模型中,第三方应用如何查询和操作服务端的受保护的资源是一个问题
   简单举几个例子,用户浏览一个网站,想要在其网站上留言,往往需要进行注册登录操作,由于流程过于复杂,提高了用户的操作成本.再比如说第三方机构想要在用户许可后获得其信用积分,或者在其社交平台上发布消息.显然用户不能直接在第三方机构上输入用户信息.Oauth的诞生可以解决上述两个问题.第一个问题本质上就是第三方应用查询用户信息功能,只需要确认该用户存在,该第三方用户就承认该用户注册成功.第二个问题显然是第三方机构操作服务端受保护的资源的例子.

OAuth2 角色设定

Oauth2定义了4种角色
resource owner  资源拥有者
指的是一个可以授权访问被保护资源的个体,例如一个个实体用户，他们的用户信息就是资源。

resource server 资源服务器
指的是用来托管受保护的资源,例如某个具体具体服务模块

client 客户端
指的是利用资源拥有者的授权信息去请求被保护的资源的各种第三方服务,例如第三方服务机构

authorization server 授权服务器
在资源拥有者授权后,向客户端授权(颁发 access,tokens)的服务器,例如支付宝验证登陆
资源服务器与授权服务器之间的交互是属于被访问者自己内部的事情，资源服务器与授权服务器可以是同一个。对于支付宝来说，一个授权服务器,可以向多个资源服务器颁发acess token服务

OAuth2  授权流程

step 1:客户端预先在授权服务器上注册,获得app_id
step 2:资源拥有者向客户端请求访问
step 3:客户端需要对该资源拥有者进行身份验证,遂重定向至授权服务器
step 4:在授权服务器上,资源拥有者同意给予客户端授权AuthorizationCode
step 5:资源服务器重定向至客户端并向客户端提供授权AuthorizationCode
step 6:客户端使用上一步获得的授权AuthorizationCode和自己的app_id,向授权服务器申请令牌access token
step 7:授权服务器对客户端进行认证后,同意发放令牌access token.
step 8:客户端使用令牌access token,向资源服务器申请资源.
step 9:资源服务器确认令牌,并向客户端开放资源.

以上是详细过程,其中step 1,6,7,8,9对于资源拥有者是不可见的,仅从资源拥有者角度分析:
(A)用户打开客户端
(B)被重定向至资源服务器，选择使用资源服务器提供的授权方式授权.
(C)重定向至客户端并携带AuthorizationCode操作

上面两步也是自动完成的,客户端和资源服务器会将需要重定向的url放置在Location中,资源拥有者可以抓包获取.

为何在用户同意授权后仍需要在客户端换取acess token,而不是客户端直接使用AuthorizationCode操作。主要原因有两点:
1 该AuthorizationCode只能说明用户准许授权,而没有说明是什么应用,需要使用第三方平台预先注册时获取的request token和秘钥进行验证.
2 由于是重定向方式,所以该AuthorizationCode可能被传输过程中的应用获取(至少可以被资源拥有者的浏览器获取,如果用户浏览器不安全就会泄露授权码),无法确认资源拥有者的浏览器的安全性,所以由客户端使用AuthorizationCode结合秘钥(或者说app_id,总之就是注册时候获取到的)更为安全.

 

OAuth2与OAuth1的比较

Oauth1的access token是永久有效(或者生命周期非常长)的,而Oauth2采用了access token和refresh token互补的方式来保障安全.access token生命周期较短,而refresh token生命周期较长.当access token 生命周期过后，可以使用refresh token重新申请.简单来说就是客户端隔一段时间固定查询已过期的access token,并使用refresh token重新向授权服务器申请,更新access token和refresh token
Oauth2通过HTTPS发送，从而替换了通过 HMAC和token secret加密并发送的方式减少了实现成本.

OAuth2与OpenID的比较

openID是身份验证,OAuth2是授权,只不过授权过程中往往需要验证用户信息,所以OAuth2可以用来作为身份验证.

两者比较大的区别是OAuth2只允许第三方应用使用自己的接口,而openID则相当于自己作为第三方应用，允许其他的验证方式.

无非就是站的角度不一样,OAuth2中的第三方应用就类似于openID的任意接入方,只不过openID是平等的.从授权服务器一方，肯定希望自己管理账户方便，不需要兼容其他应用账户，对于第三方应用也只需要兼容少量常用登陆方式，更何况OAuth2还可以在验证的基础上提供资源授权的功能.这也许是OAuth2更受欢迎的原因.

参考文献

http://www.rfcreader.com/#rfc6749_line564

http://www.cnblogs.com/neutra/archive/2012/07/26/2609300.html

支付宝OAuth2流程:https://fuwu.alipay.com/platform/doc.htm#c0205