oauth2开放认证协议原理及案例分析.docx
《oauth2开放认证协议原理及案例分析.docx》由会员分享，可在线阅读，更多相关《oauth2开放认证协议原理及案例分析.docx（9页珍藏版）》请在冰豆网上搜索。
oauth2开放认证协议原理及案例分析
oauth2开放认证协议原理及案例分析
Postedon2011-08-03bykejibo
之前翻译过一篇
OAuth认证协议原理分析及使用方法
，虽然OAuth2还没有正式发布，但是国内外的OAuth2的采用情况几乎要完全替代掉了。
像淘宝、腾讯、人人网、XX开放平台就已经采用Oauth2，新浪微博也发来邮件说是要很快上马OAuth2，彻底替换掉。
目前OAuth2到了
v20草稿阶段
，最新的版本是2011年7月25号发布的，协议变化还是很快的，所以看到国内的一些已经实现的实例，再比照官方的oauth2，会有些出入的。
为何要OAuth2来替换
一、OAuth2大大简化了认证流程，OAuth1版本，我都感觉有些流程设计不是为安全性而存在，有些东西很难想一个理由，他们为何要弄得如此复杂。
复杂可能是增加安全性的一个要素，但是也极大增加了开发者的开发难度。
二、增加了对多种不同方式的认证，原来的认证只能直接或间接通过浏览器，现在有专门的标准来给客户端程序、移动应用、浏览器应用提供认证的方法。
OAuth2的四种角色
resourceowner资源所有者：
比如twitter用户，他在twitter的数据就是资源，他自己就是这些资源的所有者。
resourceserver资源服务器：
保存资源的服务器，别人要访问受限制的资源就要出示AccessToken（访问另牌）。
client客户端：
一个经过授权后，可以代表资源所有者访问资源服务器上受限制资源的一方。
比如开发者开发的应用。
authorizationserver授权服务器：
对资源所有者进行认证，认证通过后，向客户端发放AccessToken（访问另牌）。
OAuth2取得AccessToken的四种方式
一、AuthorizationCode授权码方式：
这种是推荐使用的，也是最安全的，也是替换的一种授权方式。
流程：
1、引导用户访问授权服务器，比如地址：
1
2
3
GET/authorizeresponse_type=code&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/
Host:
，其中response_type值固定为code，client_id就是客户端申请开发者的时候取得的appkey，state是一个可选参数，可以用于保存客户端在引导用户转向前的一些状态，当回到redirect_uri的时候会原封不动的传回来，redirect_uri是当用户确认授权应用访问的时候跳转回来的地址。
2，用户同意授权后跳转回来的的地址如：
1
2
3
HTTP/302Found
Location:
&state=xyz
&state=xyz，其中code就是AuthorizationCode，state就是上面所说的可选参数。
3，使用取得的AuthorizationCode去换取AccessToken：
1
2
3
4
5
6
7
POST/tokenHTTP/
Host:
Authorization:
BasicczZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
其中Authorization是由Clientid（appkey）及Clientpassword（appsecret）组合成的httpbasic验证字符串，grant_type必须为authorization_code，code是上一步取得的AuthorizationCode，redirect_uri是完成后跳转回来的网址。
如果Client不能发送Authorization信息，则可以使用下面的方式，/token这个地址必须是https连接的，不然就有泄露clientsecret的可能性：
1
2
3
4
5
6
POST/tokenHTTP/
Host:
Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA
&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
成功的话返回的信息为：
1
2
3
4
5
6
7
8
9
10
11
12
HTTP/200OK
Content-Type:
application/json;charset=UTF-8
Cache-Control:
no-store
Pragma:
no-cache
{
"access_token":
"2YotnFZFEjr1zCsicMWpAA",
"token_type":
"example",
"expires_in":
3600,
"refresh_token":
"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":
"example_value"
}
二、ImplicitGrant隐式授权：
相比授权码授权，隐式授权少了第一步的取AuthorizationCode的过程，而且不会返回refresh_token。
主要用于无服务器端的应用，比如浏览器插件。
隐式授权不包含Client授权，它的授权依赖于资源所有者及注册应用时候所填写的redirectionURI（跳转地址）。
因为Accesstoken是附着在redirect_uri上面被返回的，所以这个Accesstoken就可能会暴露给资源所有者或者设置内的其它方（对资源所有者来说，可以看到redirect_uri，对其它方来说，可以通过监测浏览器的地址变化来得到Accesstoken）。
流程
一、引导用户访问一个专门的授权页面，如
1
2
3
GET/authorizeresponse_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/
Host:
这里的response_type为token，client_id为appkey。
可以看到这里取Accesstoken的过程中并没有像第一种方式那样传入client_secret。
因为如果你传入client_secret，其实就是相当于告诉用户，你应用的appsecret了。
二、在成功授权后，跳转回到redirect_uri所定义的网址
1
2
3
HTTP/302Found
Location:
rd#access_token=2YotnFZFEjr1zCsicMWpAA
&state=xyz&token_type=example&expires_in=3600
，这样应用就可以通过取地址中的fragment部分来取得accesstoken。
三、ResourceOwnerPasswordCredentials资源所有者密码证书授权：
这种验证主要用于资源所有者对Client有极高的信任度的情况，比如操作系统或高权限程序。
只有在不能使用其它授权方式的情况下才使用这种方式。
流程：
一、提交信息到取token页面
1
2
3
4
5
6
POST/tokenHTTP/
Host:
Authorization:
BasicczZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
grant_type=password&username=johndoe&password=A3ddj3w
这里的Authorization是client_id为username，client_secret为password的httpbasic验证码。
grant_type必须为password，username为用户名，password为用户密码。
取得的结果如下：
1
2
3
4
5
6
7
8
9
10
11
12
HTTP/200OK
Content-Type:
application/json;charset=UTF-8
Cache-Control:
no-store
Pragma:
no-cache
{
"access_token":
"2YotnFZFEjr1zCsicMWpAA",
"token_type":
"example",
"expires_in":
3600,
"refresh_token":
"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":
"example_value"
}
Q:
为何要这种这么不安全的方式？
A:
取代原来原始的username，password的授权方式，而且不需要client保存用户的密码，client只要保存accesstoken就可以。
主要用于客户端程序。
四、ClientCredentials客户端证书授权：
这种情况下Client使用自己的client证书（如client_id及client_secret组成的httpbasic验证码）来获取accesstoken，只能用于信任的client。
流程：
一、提交参数取accesstoken
1
2
3
4
5
6
POST/tokenHTTP/
Host:
Authorization:
BasicczZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
grant_type=client_credentials
其中Authorization是client_id及client_secret组成的httpbasic验证串。
grant_type必须为client_credentials，
返回如下：
1
2
3
4
5
6
7
8
9
10
11
HTTP/200OK
Content-Type:
application/json;charset=UTF-8
Cache-Control:
no-store
Pragma:
no-cache
{
"access_token":
"2YotnFZFEjr1zCsicMWpAA",
"token_type":
"example",
"expires_in":
3600,
"example_parameter":
"example_value"
}
国内一些oauth2案例分析
标准的oauth2中，使用accesstoken来向资源服务器发出请求，取得资源。
这里的资源服务器需要使用https协议，否则accesstoken极可能被其它方获取。
比如
1
2
3
GET/resource/1HTTP/
Host:
Authorization:
Bearer7Fjfp0ZBr1KtDRbnfVdmIw
bearer是指token类型
，后面的字符串就是accesstoken。
还有一种
mac类型的token（目前v20版本的草稿里还没有文档）
，如：
1
2
3
4
5
GET/resource/1HTTP/
Host:
Authorization:
MACid="h480djs93hd8",
nonce="274312:
dj83hs9s",
mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
，因为https速度相较http慢，而且并非所有服务器或客户都支持https，所以国内一些网站采用一种http也可访问资源的方式。
淘宝开放平台的方式
：
应用通过用户授权获取的AccessToken的值即等同于Sessionkey，应用凭借AccessToken调用taobaoAPI即可。
查看淘宝SDK，可以看到其使用应用的app_secret作用密码钥来进行签名，参数里面包含了这个Sessionkey，这样淘宝在收到这个请求的时候，根据app_id来判断是哪个应用，根本sessionkey的值来判断是哪个用户，如果不传这个sessionkey就用app_id查得app_id所属的淘宝用户就行了。
也就是说sessionkey必须配合这个client自己的授权资料appkeyappsrecet来访问资源。
XX开放平台方式
、
人人网方式
、还有腾讯也类似：
在返回accesstoken的同时返回sessionKey及sessionSecret。
如：
1
2
3
4
5
6
7
8
{
"access_token":
"",
"expires_in":
86400,
"refresh_token":
"",
"scope":
"basicemail",
"session_key":
"9XNNXe66zOlSassjSKD5gry9BiN61IUEi8IpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A=",
"session_secret":
"27e1be4fdcaa83d7f61c489994ff6ed6",
}
在调用资源API的时候，如下：
1
2
GET/rest/passport/users/getInfosession_key=9XNNXe66zOlSassjSKD5gry9BiN61IUEi8IpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A%3D×tamp=2011-06-21+17%3A18%3A09&format=json&uid=&sign=d24dd357a95a2579c410b3a92495f009HTTP/
Host:
这里参数里面的session_key，传给服务器后，用户查询session_secret，sign使用session_secret作为密钥来加密的。
可以看到这里调用的时候没有使用client_id或client_secret信息，所以对于任何获取
1
2
"session_key":
"9XNNXe66zOlSassjSKD5gry9BiN61IUEi8IpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A=",
"session_secret":
"27e1be4fdcaa83d7f61c489994ff6ed6",
的一方都可以调用到API。
降低系统耦合度。
Thisentrywaspostedin未分类andtaggedoauth2bykejibo.Bookmarkthepermalink.
升级会员 