oauth2开放认证协议原理及案例分析.docx
《oauth2开放认证协议原理及案例分析.docx》由会员分享,可在线阅读,更多相关《oauth2开放认证协议原理及案例分析.docx(8页珍藏版)》请在冰豆网上搜索。
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、弓I导用户访问授权服务器,比如地址:
1GET/authorize?
response_type=code&client_id=s6BhdRkqt3&state=xyz
2&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/
3Host:
,其中response_type值固定为code,client_id就是客户端申请开发者的
时候取得的appkey,state是一个可选参数,可以用于保存客户端在引导用户转向前的一些状态,当回到redirect_uri的时候会原封不动的传回来,
redirect_uri是当用户确认授权应用访问的时候跳转回来的地址。
2,用户同意授权后跳转回来的的地址如:
1HTTP/302Found
2Location:
&state=xyz
&state=xyz,其中code就是AuthorizationCode,state就是上面所说的可选参数。
3,使用取得的AuthorizationCode去换取AccessToken:
?
1POST/tokenHTTP/
2Host:
3Authorization:
BasicczZCaGRSa3F0MzpnWDFmQmF0M2JW
4Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
6=authorization_code&code=SplxlOBeZQQYbYS6WxSblA
7&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的可能性:
?
1POST/tokenHTTP/
2Host:
3Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
4
4grant_type=refresh_token&refresh_token=tGzv3JOkFOXG5Qx2TlKWIA
5&client_id=s6BhdRkqt3&client_secret=7FjfpOZBr1KtDRbnfVdmlw
成功的话返回的信息为:
?
1HTTP/200OK
2Content-Type:
application/json;charset=UTF-8
3Cache-Control:
no-store
4Pragma:
no-cache
6"access_token":
"2YotnFZFEjrlzCsicMWpAA",
7"token_type":
"example",
8"expires_in":
3600,
9"refresh_token":
"tGzv3JOkFOXG5Qx2TlKWIA",
10"example_parameter":
"example_value"
11}
二>ImplicitGrant隐式授权:
相比授权码授权,隐式授权少了第一步的取
AuthorizationCode的过程,而且不会返回refresh_token。
主要用于无服
务器端的应用,比如浏览器插件。
隐式授权不包含Client授权,它的授权
依赖于资源所有者及注册应用时候所填写的redirectionURI(跳转地址)。
因为Accesstoken是附着在redirect_uri上面被返回的,所以这个Access
token就可能会暴露给资源所有者或者设置内的其它方(对资源所有者来说,可以看到redirect_uri,对其它方来说,可以通过监测浏览器的地址变化来
得至UAccesstoken)。
流程
一、引导用户访问一个专门的授权页面,如
1GET/authorize?
response_type=token&client_id=s6BhdRkqt3&state=xyz
2&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/
3Host:
这里的response_type为token,client_id为appkey。
可以看至U这里取
Accesstoken的过程中并没有像第一种方式那样传入client_secret。
因为如果你传入client_secret,其实就是相当于告诉用户,你应用的appsecret
了。
二、在成功授权后,跳转回到redirect_uri所定义的网址
1HTTP/302Found
2Location:
rd#access_token=2YotnFZFEjrlzCsicMWpAA
3&state=xyz&token_type=example&expires_in=3600
,这样应用就可以通过取地址中的fragment部分来取得accesstoken。
三、ResourceOwnerPasswordCredentials资源所有者密码证书授权:
这种验证主要用于资源所有者对Client有极高的信任度的情况,比如操作系统或高权限程序。
只有在不能使用其它授权方式的情况下才使用这种方式。
流程:
一、提交信息到取token页面
1POST/tokenHTTP/
2Host:
3Authorization:
BasicczZCaGRSa3F0MzpnWDFmQmF0M2JW
4Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
5
5grant_type=password&username=johndoe&password=A3ddj3w
这里的Authorization是client_id为username,client_secret为password的httpbasic验证码。
grant_type必须为password,username为用户名,password为用户密码。
取得的结果如下:
1HTTP/200OK
2Content-Type:
application/json;charset=UTF-8
3Cache-Control:
no-store
4Pragma:
no-cache
5
5{
6"access_token":
"2YotnFZFEjr1zCsicMWpAA",
7"token_type":
"example",
8"expires_in":
3600,
9"refresh_token":
"tGzv3JOkFOXG5Qx2TlKWIA",
10"example_parameter":
"example_value"
11}
Q:
为何要这种这么不安全的方式?
A:
取代原来原始的username,password的授权方式,而且不需要client保
存用户的密码,client只要保存accesstoken就可以。
主要用于客户端程序。
四、ClientCredentials客户端证书授权:
这种情况下Client使用自己的
client证书(如client_id及client_secret组成的httpbasic验证码)
来获取accesstoken,只能用于信任的client。
流程:
一、提交参数取accesstoken
1POST/tokenHTTP/
2Host:
3Authorization:
BasicczZCaGRSa3F0MzpnWDFmQmF0M2JW
4Content-Type:
application/x-www-form-urlencoded;charset=UTF-8
5
5grant_type=client_credentials
其中Authorization
是clientid
及clientsecret组成的httpbasic验
证串。
grant_type
返回如下:
?
必须为client_
_credentials,
1HTTP/200OK
2Content-Type:
application/json;charset=UTF-8
3Cache-Control:
no-store
4Pragma:
no-cache
5
5{
6"access_token":
"2YotnFZFEjr1zCsicMWpAA",
7"token_type":
"example",
8"expires_in":
3600,
9"example_parameter":
"example_value"
国内一些QAUTH2案例分析
标准的oauth2中,使用accesstoken来向资源服务器发出请求,取得资源。
这里的资源服务器需要使用https协议,否则accesstoken极可能被其它方获取。
比如
?
1GET/resource/1HTTP/
2Host:
3Authorization:
Bearer7FjfpOZBr1KtDRbnfVdmlw
bearer是指token类型
,后面的字符串就是accesstoken。
还有一种mac类型的token(目前v20版本的草稿里还没有文档),如:
1GET/resource/1HTTP/
2Host:
3Authorization:
MACid="h480djs93hd8",
4nonce="274312:
dj83hs9s",
5mac="kDZvddkndxvhGRXZhvuDjEWhGeE="
,因为https速度相较http慢,而且并非所有服务器或客户都支持https,所以国
内一些网站采用一种http也可访问资源的方式。
淘宝开放平台的方式
:
应用通过用户授权获取的AccessToken的值即等同于Sessionkey,应用凭借
AccessToken调用taobaoAPI即可。
查看淘宝SDK可以看到其使用应用的app_secret作用密码钥来进行签名,参数里面包含了这个Sessionkey,这样淘宝
在收到这个请求的时候,根据app_id来判断是哪个应用,根本sessionkey的值来
判断是哪个用户,如果不传这个sessionkey就用app_id查得app_id所属的淘宝
用户就行了。
也就是说sessionkey必须配合这个client自己的授权资料appkey
appsrecet来访问资源。
XX开放平台方式
、
人人网方式
、还有腾讯也类似:
在返回accesstoken的同时返回sessionKey及
sessionSecret。
如:
"accesstoken":
""
2-
3"expires_in":
86400,
"refreshtoken":
"",
4-
"scope":
"basicemail",
5
"sessionkey":
6
"9XNNXe66zOlSassjSKD5gry9BiN61IUEi8lpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A=",
7"session_secret":
"27e1be4fdcaa83d7f61c489994ff6ed6",8}
在调用资源API的时候,如下:
GET
/rest/passport/users/getlnfo?
session_key=9XNNXe66zOISassjSKD5gry9BiN61IUEi8lpJmjB
1_
wvU07RXP0J3c4GnhZR3GKhMHa1A%3D×tamp=2011-06-21+17%3A18%3A09&format=json&uid=
&sign=d24dd357a95a2579c410b3a92495f009HTTP/
2
Host:
这里参数里面的session_key,传给服务器后,用户查询session_secret,sign
使用session_secret作为密钥来加密的。
可以看到这里调用的时候没有使用
client_id或client_secret信息,所以对于任何获取
"session_key":
"9XNNXe66zOlSassjSKD5gry9BiN61IUEi8lpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A=",2"session_secret":
"27e1be4fdcaa83d7f61c489994ff6ed6",
的一方都可以调用到API。
降低系统耦合度。
Thisentrywaspostedin未分类andtaggedoauth2bykejibo.Bookmarkthepermalink.