oauth2开放认证协议原理及案例分析.docx

1、oauth2开放认证协议原理及案例分析oauth2开放认证协议原理及案例分析Posted on 2011-08-03 by kejibo之前翻译过一篇OAuth认证协议原理分析及使用方法，虽然OAuth2还没有正式发布，但是国内外的 OAuth2的采用情况几乎要完全替代 掉了。像淘宝、腾讯、人人网、XX开放平台就已经采用 Oauth2,新浪微博也发来邮件说是要很快上马OAuth2，彻底替换掉。目前OAuth2到了v20草稿阶段，最新的版本是2011年7月25号发布的，协议变化还是很快的，所以看到国内的 一些已经实现的实例，再比照官方的 oauth2，会有些出入的。为何要 OAUTH2来替换？一

2、、 OAuth2大大简化了认证流程，OAuth1版本，我都感觉有些流程设计不 是为安全性而存在，有些东西很难想一个理由，他们为何要弄得如此复杂。 复杂可能是增加安全性的一个要素，但是也极大增加了开发者的开发难度。二、 增加了对多种不同方式的认证，原来的认证只能直接或间接通过浏览器, 现在有专门的标准来给客户端程序、移动应用、浏览器应用提供认证的方法。OAUTH2的四种角色resource owner资源所有者：比如twitter 用户，他在twitter 的数据就是 资源，他自己就是这些资源的所有者。resource server 资源服务器：保存资源的服务器，别人要访问受限制的资 源就要出示

3、Access Token （访问另牌）。client客户端：一个经过授权后，可以代表资源所有者访问资源服务器上受 限制资源的一方。比如 开发者开发的应用。authorization server授权服务器：对 资源所有者进行认证，认证通过后， 向 客户端发放Access Token （访问另牌）。OAUTH2取 得 ACCESS TOKEN的四 种方式一、Authorization Code 授权码方式：这种是推荐使用的，也是最安全的,也是替换的一种授权方式。流程：1、弓I导用户访问授权服务器，比如地址：1GET /authorize?resp on se_type=code&clie nt_

4、id=s6BhdRkqt3&state=xyz2& redirect_uri=https%3A%2F%2Fclie nt%2Eexample%2Ecom%2Fcb HTTP/3Host:，其中response_type 值固定为code , client_id 就是客户端申请开发者的时候取得的appkey , state是一个可选参数，可以用于保存客户端在引导用 户转向前的一些状态，当回到 redirect_uri 的时候会原封不动的传回来，redirect_uri 是当用户确认授权应用访问的时候跳转回来的地址。2,用户同意授权后跳转回来的的地址如：1HTTP/ 302 Found2Locat

5、i on:&state=xyz&state=xyz ，其中 code 就是 Authorization Code ，state 就是上面所说的 可选参数。3，使用取得的 Authorization Code 去换取 Access Token :?1POST /token HTTP/2Host:3Authorizatio n: Basic czZCaGRSa3F0Mzp nWDFmQmF0M2JW4Conten t-Type: applicatio n/x-www-form-urle ncoded;charset=UTF-86=authorization_code&code=SplxlOBeZQ

6、QYbYS6WxSblA7& redirect_uri=https%3A%2F%2Fclie nt%2Eexample%2Ecom%2Fcb其中 Authorization 是由 Client id(app key)及 Client password(app secret) 组合成的 http basic 验证字符串，grant_type 必须为 authorization_code ,code是上一步取得的Authorization Code , redirect_uri 是完成后跳转回来的网址。如果Client不能发送Authorization 信息，则可以使用下面的方式，/token 这

7、个地址必须是https连接的，不然就有泄露 client secret 的可能性：?1POST /token HTTP/2Host:3Conten t-Type: applicatio n/x-www-form-urle ncoded;charset=UTF-844gran t_type=refresh_toke n&refresh_toke n=tGzv3JOkFOXG5Qx2TlKWIA5& clie nt_id=s6BhdRkqt3&clie nt_secret=7FjfpOZBr1KtDRb nfVdmlw成功的话返回的信息为：?1HTTP/ 200 OK2Conten t-Type:

8、 applicati on/json ;charset=UTF-83Cache-Co ntrol: no-store4Pragma: no-cache6access_toke n:2Yot nFZFEjrlzCsicMWpAA,7toke n_type:example,8expires_i n:3600,9refresh_toke n:tGzv3JOkFOXG5Qx2TlKWIA,10example_parameter:example_value11二 Implicit Grant隐式授权：相比授权码授权，隐式授权少了第一步的取Authorization Code 的过程，而且不会返回refr

9、esh_toke n 。主要用于无服务器端的应用，比如 浏览器插件。隐式授权不包含 Client授权，它的授权依赖于资源所有者及注册应用时候所填写的 redirection URI （跳转地址）。因为Access token是附着在redirect_uri 上面被返回的，所以这个 Accesstoken就可能会暴露给资源所有者或者设置内的其它方（对资源所有者来说， 可以看到redirect_uri ，对其它方来说，可以通过监测浏览器的地址变化来得至U Access token ）。流程一、引导用户访问一个专门的授权页面，如1GET /authorize?resp on se_type=toke

10、 n&clie nt_id=s6BhdRkqt3&state=xyz2& redirect_uri=https%3A%2F%2Fclie nt%2Eexample%2Ecom%2Fcb HTTP/3Host:这里的response_type 为token，client_id 为appkey。可以看至U这里取Access token的过程中并没有像 第一种方式那样传入 client_secret 。因为 如果你传入client_secret ，其实就是相当于告诉用户， 你应用的app secret了。二、在成功授权后，跳转回到 redirect_uri 所定义的网址1HTTP/ 302 Fou

11、nd2Locati on: rd#access_toke n=2Yot nFZFEjrlzCsicMWpAA3&state=xyz&toke n_type=example&expires_ in=3600，这样应用就可以通过取地址中的 fragment部分来取得access token 。三、Resource Owner Password Credentials 资源所有者密码证书授权：这 种验证主要用于资源所有者对 Client有极高的信任度的情况，比如操作系统 或高权限程序。只有在不能使用其它授权方式的情况下才使用这种方式。流程：一、提交信息到取token页面1POST /token HT

12、TP/2Host:3Authorizatio n: Basic czZCaGRSa3F0Mzp nWDFmQmF0M2JW4Conten t-Type: applicatio n/x-www-form-urle ncoded;charset=UTF-855gran t_type=password&username=joh ndoe&password=A3ddj3w这里的 Authorizati on 是 clie nt_id 为 user name, clie nt_secret 为 password 的 http basic 验证码。gran t_type 必须为 password，user

13、 name 为 用户名，password为用户密码。取得的结果如下：1HTTP/ 200 OK2Conten t-Type: applicati on/json ;charset=UTF-83Cache-Co ntrol: no-store4Pragma: no-cache556access_toke n:2Yot nFZFEjr1zCsicMWpAA,7toke n_type:example,8expires_i n:3600,9refresh_toke n:tGzv3JOkFOXG5Qx2TlKWIA,10example_parameter:example_value11Q:为何要这种这么

14、不安全的方式？A:取代原来原始的username, password的授权方式，而且不需要 client 保存用户的密码，client只要保存access token就可以。主要用于客户端程序。四、Client Credentials 客户端证书授权：这种情况下 Client 使用自己的client 证书（如 client_id 及 client_secret 组成的 http basic 验证码）来获取access token ，只能用于信任的 client。流程：一、提交参数取 access token1POST /token HTTP/2Host:3Authorizatio n: Bas

15、ic czZCaGRSa3F0Mzp nWDFmQmF0M2JW4Conten t-Type: applicatio n/x-www-form-urle ncoded;charset=UTF-855gran t_type=clie nt_crede ntials其中 Authorizati on是 client id及 client secret 组成的 http basic 验证串。grant_type返回如下：?必须为client_creden tials ,1 HTTP/ 200 OK2Conten t-Type: applicati on/json; charset=UTF-83Cac

16、he-C on trol: no-store4Pragma: no-cache556access_toke n:2Yot nF ZFEjr1zCsicMWpAA,7token_type:example,8expires_i n :3600,9example_parameter:example_value国内一些QAUTH2案例分析标准的oauth2中，使用access token来向资源服务器发出请求，取得资源。这里 的资源服务器需要使用https协议，否则access token极可能被其它方获取。比 如?1GET /resource/1 HTTP/2Host:3Authorizati on

17、: Bearer 7FjfpOZBr1KtDRb nfVdmlwbearer是指token 类型，后面的字符串就是access token。还有一种 mac类型的token （目前v20版本的草稿里还没有文档） ，如：1GET /resource/1 HTTP/2Host:3Authorization: MAC id=h480djs93hd8,4non ce=274312:dj83hs9s,5mac=kDZvddk ndxvhGRXZhvuDjEWhGeE=，因为https速度相较http慢，而且并非所有服务器或客户都支持 https，所以国内一些网站采用一种http也可访问资源的方式。淘宝开

18、放平台的方式:应用通过用户授权获取的 AccessToken的值即等同于Sessionkey，应用凭借AccessToken调用taobao API即可。查看淘宝SDK可以看到其使用应用的 app_secret作用密码钥来进行签名，参数里面包含了 这个Sessionkey，这样淘宝在收到这个请求的时候，根据 app_id来判断是哪个应用，根本 sessionkey的值来判断是哪个用户，如果不传这个 sessionkey就用app_id查得app_id所属的淘宝用户就行了。也就是说sessionkey必须配合这个client 自己的授权资料appkeyappsrecet来访问资源。XX开放平台方

19、式、人人网方式、还有腾讯也类似：在返回 access token 的同时返回sessionKey及sessi on Secret 。如：access token:2 -3expires_i n: 86400,refresh token:,4-scope: basic email,5session key:69XNNXe66zOlSassjSKD5gry9BiN61IUEi8lpJmjBwvU07RXP0J3c4G nhZR3GKhMHa1A=,7 session_secret: 27e1be4fdcaa83d7f61c489994ff6ed6, 8在调用资源API的时候，如下:GET/rest

20、/passport/users/getl nfo?session_key=9XNNXe66zOISassjSKD5gry9BiN61IUEi8lpJmjB1 _wvU07RXP0J3c4G nhZR3GKhMHa1A%3D×tamp=2011-06-21+17%3A18%3A09 &format=jso n&uid=&sig n=d24dd357a95a2579c410b3a92495f009 HTTP/2Host:这里参数里面的session_key，传给服务器后，用户查询 session_secret , sign使用session_secret作为密钥来加密的。可以看到这里调用的时候没有使用client_id 或client_secret 信息，所以对于任何获取sessi on _key:9XNNXe66zOlSassjSKD5gry9BiN61IUEi8lpJmjBwvU07RXP0J3c4G nhZR3GKhMHa1A=, 2 session_secret: 27e1be4fdcaa83d7f61c489994ff6ed6,的一方都可以调用到API。降低系统耦合度。This entry was posted in 未分类 and tagged oauth2 by kejibo . Bookmark the permalink .