oauth2开放认证协议原理及案例分析.docx
- 文档编号:17338873
- 上传时间:2023-07-24
- 格式:DOCX
- 页数:9
- 大小:18.66KB
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.
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- oauth2 开放 认证 协议 原理 案例 分析