oauth2開放認證協(xié)議原理及案例分析編制僅供參考審核批準生效日期地址：電話：傳真:郵編:oauth2開放認證協(xié)議原理及案例分析Postedon2011-08-03bykejibo之前翻譯過一篇

OAuth認證協(xié)議原理分析及使用方法

，雖然OAuth2還沒有正式發(fā)布，但是國內外的OAuth2的采用情況幾乎要完全替代掉OAuth1.1了。像淘寶、騰訊、人人網(wǎng)、百度開放平臺就已經(jīng)采用Oauth2，新浪微博也發(fā)來郵件說是要很快上馬OAuth2，徹底替換掉OAuth1.1。目前OAuth2到了

v20草稿階段

，最新的版本是2011年7月25號發(fā)布的，協(xié)議變化還是很快的，所以看到國內的一些已經(jīng)實現(xiàn)的實例，再比照官方的oauth2，會有些出入的。為何要OAuth2來替換OAuth1.1？一、OAuth2大大簡化了認證流程，OAuth1版本，我都感覺有些流程設計不是為安全性而存在，有些東西很難想一個理由，他們?yōu)楹我萌绱藦碗s。復雜可能是增加安全性的一個要素，但是也極大增加了開發(fā)者的開發(fā)難度。二、增加了對多種不同方式的認證，原來的認證只能直接或間接通過瀏覽器，現(xiàn)在有專門的標準來給客戶端程序、移動應用、瀏覽器應用提供認證的方法。OAuth2的四種角色resourceowner資源所有者：比如twitter用戶，他在twitter的數(shù)據(jù)就是資源，他自己就是這些資源的所有者。resourceserver資源服務器：保存資源的服務器，別人要訪問受限制的資源就要出示AccessToken（訪問另牌）。client客戶端：一個經(jīng)過授權后，可以代表資源所有者訪問資源服務器上受限制資源的一方。比如開發(fā)者開發(fā)的應用。authorizationserver授權服務器：對資源所有者進行認證，認證通過后，向客戶端發(fā)放AccessToken（訪問另牌）。OAuth2取得AccessToken的四種方式一、AuthorizationCode授權碼方式：這種是推薦使用的，也是最安全的，也是替換OAuth1.1的一種授權方式。流程：1、引導用戶訪問授權服務器，比如地址：123GET/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz

&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/1.1Host:，其中response_type值固定為code，client_id就是客戶端申請開發(fā)者的時候取得的appkey，state是一個可選參數(shù)，可以用于保存客戶端在引導用戶轉向前的一些狀態(tài)，當回到redirect_uri的時候會原封不動的傳回來，redirect_uri是當用戶確認授權應用訪問的時候跳轉回來的地址。2，用戶同意授權后跳轉回來的的地址如：123HTTP/1.1302FoundLocation:/cb?code=SplxlOBeZQQYbYS6WxSbIA

&state=xyz&state=xyz，其中code就是AuthorizationCode，state就是上面所說的可選參數(shù)。3，使用取得的AuthorizationCode去換取AccessToken：1234567POST/tokenHTTP/1.1Host:Authorization:BasicczZCaGRSa3F0MzpnWDFmQmF0M2JWContent-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是完成后跳轉回來的網(wǎng)址。如果Client不能發(fā)送Authorization信息，則可以使用下面的方式，/token這個地址必須是https連接的，不然就有泄露clientsecret的可能性：123456POST/tokenHTTP/1.1Host:Content-Type:application/x-www-form-urlencoded;charset=UTF-8

grant_type=refresh_token&refresh_token=tGzv3JOkF0XG5Qx2TlKWIA&client_id=s6BhdRkqt3&client_secret=7Fjfp0ZBr1KtDRbnfVdmIw成功的話返回的信息為：123456789101112HTTP/1.1200OKContent-Type:application/json;charset=UTF-8Cache-Control:no-storePragma: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，對其它方來說，可以通過監(jiān)測瀏覽器的地址變化來得到Accesstoken）。流程一、引導用戶訪問一個專門的授權頁面，如123GET/authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz

&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2FcbHTTP/1.1Host:這里的response_type為token，client_id為appkey。可以看到這里取Accesstoken的過程中并沒有像第一種方式那樣傳入client_secret。因為如果你傳入client_secret，其實就是相當于告訴用戶，你應用的appsecret了。二、在成功授權后，跳轉回到redirect_uri所定義的網(wǎng)址123HTTP/1.1302FoundLocation:/rd#access_token=2YotnFZFEjr1zCsicMWpAA

&state=xyz&token_type=example&expires_in=3600，這樣應用就可以通過取地址中的fragment部分來取得accesstoken。三、ResourceOwnerPasswordCredentials資源所有者密碼證書授權：這種驗證主要用于資源所有者對Client有極高的信任度的情況，比如操作系統(tǒng)或高權限程序。只有在不能使用其它授權方式的情況下才使用這種方式。流程：一、提交信息到取token頁面123456POST/tokenHTTP/1.1Host:Authorization:BasicczZCaGRSa3F0MzpnWDFmQmF0M2JWContent-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為用戶密碼。取得的結果如下：123456789101112HTTP/1.1200OKContent-Type:application/json;charset=UTF-8Cache-Control:no-storePragma: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。流程：一、提交參數(shù)取accesstoken123456POST/tokenHTTP/1.1Host:Authorization:BasicczZCaGRSa3F0MzpnWDFmQmF0M2JWContent-Type:application/x-www-form-urlencoded;charset=UTF-8

grant_type=client_credentials其中Authorization是client_id及client_secret組成的httpbasic驗證串。grant_type必須為client_credentials，返回如下：1234567891011HTTP/1.1200OKContent-Type:application/json;charset=UTF-8Cache-Control:no-storePragma:no-cache

{

"access_token":"2YotnFZFEjr1zCsicMWpAA",

"token_type":"example",

"expires_in":3600,

"example_parameter":"example_value"}國內一些oauth2案例分析標準的oauth2中，使用accesstoken來向資源服務器發(fā)出請求，取得資源。這里的資源服務器需要使用https協(xié)議，否則accesstoken極可能被其它方獲取。比如123GET/resource/1HTTP/1.1Host:Authorization:Bearer7Fjfp0ZBr1KtDRbnfVdmIw

bearer是指token類型

，后面的字符串就是accesstoken。還有一種

mac類型的token（目前v20版本的草稿里還沒有文檔）

，如：12345GET/resource/1HTTP/1.1Host:Authorization:MACid="h480djs93hd8",

nonce="274312:dj83hs9s",

mac="kDZvddkndxvhGRXZhvuDjEWhGeE="，因為https速度相較http慢，而且并非所有服務器或客戶都支持https，所以國內一些網(wǎng)站采用一種http也可訪問資源的方式。

淘寶開放平臺的方式

：應用通過用戶授權獲取的AccessToken的值即等同于Sessionkey，應用憑借AccessToken調用taobaoAPI即可。查看淘寶SDK，可以看到其使用應用的app_secret作用密碼鑰來進行簽名，參數(shù)里面包含了這個Sessionkey，這樣淘寶在收到這個請求的時候，根據(jù)app_id來判斷是哪個應用，根本sessionkey的值來判斷是哪個用戶，如果不傳這個sessionkey就用app_id查得app_id所屬的淘寶用戶就行了。也就是說sessionkey必須配合這個client自己的授權資料appkeyappsrecet來訪問資源。

百度開放平臺方式

、

人人網(wǎng)方式

、還有騰訊也類似：在返回accesstoken的同時返回sessionKey及sessionSecret。如：12345678{

"access_token":"1.a6b7dbd428f731035f771b8d15063f61.86400.1292922000-2346678-124328",

"expires_in":86400,

"refresh_token":"2.385d55f8615fdfd9edb7c4b5ebdc3e39.604800.1293440400-2346678-124328",

"scope":"basicemail",

"session_key":"9XNNXe66zOlSassjSKD5gry9BiN61IUEi8IpJmjBwvU07RXP0J3c4GnhZR3GKhMHa1A=",