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

oauth2开放认证协议原理及案例分析Postedon2011-08-03bykejibo之前翻译过一篇OAuth认证协议原理分析及使用方法，虽然OAuth2还没有正式发布，但是国内外的OAuth2的采用情况几乎要完全替代掉了。像淘宝、腾讯、人人网、百度开放平台就已经采用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导用户访问授权服务器，比如地址: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,用户同意授权后跳转回来的的地址如：HTTP/302FoundLocation:&state=xyz&state=xyz，其中code就是AuthorizationCode，state就是上面所说的可选参数。3，使用取得的AuthorizationCode去换取AccessTokenPOST/tokenHTTP/Host:Authorization:BasicczZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type:application/x-www-form-urlencoded;charset=UTF-85=authorization_code&code=SplxlOBeZQQYbYS6WxSblA&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的可能性：POST/tokenHTTP/Host:Content-Type:application/x-www-form-urlencoded;charset=UTF-84grant_type=refresh_token&refresh_token=tGzv3JOkFOXG5Qx2TlKWIA&client_id=s6BhdRkqt3&client_secret=7FjfpOZBr1KtDRbnfVdmlw成功的话返回的信息为：HTTP/200OKContent-Type:application/json;charset=UTF-8Cache-Control:no-storePragma:no-cache5{"access_token":"2YotnFZFEjr1zCsicMWpAA","token_type":"example","expires_in":3600,"refresh_token":"tGzv3JOkFOXG5Qx2TlKWIA","example_parameter":"example_value"}二＞ImplicitGrant隐式授权：相比授权码授权，隐式授权少了第一步的取AuthorizationCode的过程，而且不会返回 refresh_token。主要用于无服务器端的应用，比如浏览器插件。隐式授权不包含Client授权，它的授权依赖于资源所有者及注册应用时候所填写的 redirectionURI（跳转地址）。因为Accesstoken是附着在redirect_uri上面被返回的，所以这个 Accesstoken就可能会暴露给资源所有者或者设置内的其它方（对资源所有者来说，可以看到redirect_uri，对其它方来说，可以通过监测浏览器的地址变化来得到 Accesstoken）。流程一、引导用户访问一个专门的授权页面，如GET/authorizeresponse_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/这里的response_type为token,client_id为appkey。可以看至U这里取Accesstoken的过程中并没有像第一种方式那样传入 client_secret。因为如果你传入client_secret,其实就是相当于告诉用户，你应用的 appsecret了。二、在成功授权后，跳转回到 redirect_uri所定义的网址HTTP/302FoundLocation:rd#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=example&expires_in=3600，这样应用就可以通过取地址中的 fragment部分来取得accesstoken。三、ResourceOwnerPasswordCredentials资源所有者密码证书授权：这种验证主要用于资源所有者对Client有极高的信任度的情况，比如操作系统或高权限程序。只有在不能使用其它授权方式的情况下才使用这种方式。流程：一、提交信息到取token页面POST/tokenHTTP/Host:Authorization:BasicczZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type:application/x-www-form-urlencoded;charset=UTF-8这里的Authorization是client_id为username,client_secret为password的httpbasic验证码。grant_type必须为password,username为用户名，password为用户密码。取得的结果如下:HTTP/200OKContent-Type:application/json;charset=UTF-8Cache-Control:no-storePragma:no-cache5{"access_token":"2YotnFZFEjr1zCsicMWpAA","token_type":"example","expires_in":3600,"refresh_token":"tGzv3JOkFOXG5Qx2TlKWIA","example_parameter":"example_value"}Q:为何要这种这么不安全的方式A:取代原来原始的 username,password的授权方式，而且不需要 client保存用户的密码，client只要保存accesstoken就可以。主要用于客户端程序。四、ClientCredentials客户端证书授权：这种情况下Client使用自己的client证书（如client_id及client_secret组成的httpbasic验证码）来获取accesstoken，只能用于信任的client。流程：一、提交参数取accesstokenPOST/tokenHTTP/Host:Authorization:BasicczZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type:application/x-www-form-urlencoded;charset=UTF-85grant_type=client_credentials其中Authorization是client_id及client_secret组成的httpbasic验证串。grant_type必须为client_credentials，返回如下：HTTP/200OKContent-Type:application/json;charset=UTF-8Cache-Control:no-storePragma:no-cache"access_token":"2YotnFZFEjrlzCsicMWpAA","token_type":"example","expires_in":3600,"example_parameter":"example_value"}国内一些OAUTH2案例分析标准的oauth2中，使用accesstoken来向资源服务器发出请求，取得资源。这里的资源服务器需要使用https协议，否则accesstoken极可能被其它方获取。比如GET/resource/1HTTP/Host:Authorization:Bearer7Fjfp0ZBr1KtDRbnfVdmlwbearer是指token类型，后面的字符串就是accesstoken还有一种mac类型的token（目前v20版本的草稿里还没有文档），如: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来访问资源。百度开放平台方式人人网方式、还有腾讯也类似：在返回 accesstoken的同时返回sessionKey及sessionSecret如：112345678{"access_token":"""expires,in":86400,"refresh_token":"","scope":"basicemail","session_key":"9XNNXe66zOISassjSKD5gry9BiN61IUEi8lpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A=","session_secret":"27e1be4fdcaa83d7f61c4899