开放平台_OAuth2.0
為什么出現oauth2.0
?
1 oauth1.0對手機客戶端，移動設備等非server第三方的支持不好。其實oauth1.0也是可以支持手機客戶端，移動設備等，也有相應的流程。但是oauth1.0是將多種流程合并成了一種，而事實證明，這種合并的流程體驗性非常差
2 oauth1.0的三步認證過程比較繁瑣和復雜，對第三方開發者增加了極大的開發難度
3 oauth1.0的加密需求過于復雜，第三方開發者使用oauth之前需要花費精力先實現oauth1.0的加密算法
4 oauth1.0的拓展性不夠好
5 oauth1.0生成的access_token要求是永久有效的，這導致的問題是網站的安全性和破壞網站的架構
?
因此出現了oauth2.0
?
oauth2.0針對1.0的各種問題提供了解決方法：
1 oauth2.0提出了多種流程，各個客戶端按照實際情況選擇不同的流程來獲取access_token。這樣就解決了對移動設備等第三方的支持，也解決了拓展性的問題
2 oauth2.0刪除了繁瑣的加密算法。利用了https傳輸對認證的安全性進行了保證
3 oauth2.0的認證流程一般只有2步，對開發者來說，減輕了負擔
4 oauth2.0提出了access_token的更新方案，獲取access_token的同時也獲取refresh_token, access_token是有過期時間的，refresh_token的過期時間較長，這樣能隨時使用refresh_token對access_token進行更新
oauth2.0的現狀
?
oauth2.0截止到2011/8/31 為止已經發布更新了20個版本，下面是oauth2.0的ietf標準文檔：
http://tools.ietf.org/html/draft-ietf-oauth-v2-20
?
oauth2.0得到了越來越多大公司的支持，比如microsoft，yahoo等，也在實際使用過程中不斷得到優化和完善，oauth2.0已經成為了業界通用和使用的標準。
?
oauth2.0的實現
?
oauth2.0有許多種流程，分別適應不同的第三方應用，并且這些流程數目還在不斷增加和完善中，一個網站可以實現一種或多種流程
?
比如最典型的6中流程有 :
?
User-Agent Flow 客戶端運行于用戶代理內（典型如web瀏覽器）。
Web Server Flow 客戶端是web服務器程序的一部分，通過http request接入，這是OAuth 1.0提供的流程的簡化版本。
Device Flow 適用于客戶端在受限設備上執行操作，但是終端用戶單獨接入另一臺電腦或者設備的瀏覽器
Username and Password Flow 這個流程的應用場景是，用戶信任客戶端處理身份憑據，但是仍然不希望客戶端儲存他們的用戶名和密碼，這個流程僅在用戶高度信任客戶端時才適用。
Client Credentials Flow 客戶端適用它的身份憑據去獲取access token，這個流程支持2-legged OAuth的場景。
Assertion Flow 客戶端用assertion去換取access token，比如SAML assertion。
?
?
以開心網為例（開心網是實現了oauth2.0的第10個版本）
?
開心網實現了
Web Server Flow
User-Agent Flow
Username and Password Flow
三種方式
?
http://wiki.open.kaixin001.com/index.php?id=OAuth2.0%E6%96%87%E6%A1%A3
?
oauth2.0的客戶端實現是非常方便的，開心網的說明文檔也已經非常全了，這里就不多說了
?
下面說一下各個流程的步驟：
?
Web Server Flow：
web ServerFlow是把oauth1.0的三個步驟縮略為兩個步驟
?
首先這個是適合有server的第三方使用的。
1客戶端http請求authorize
2服務端接收到authorize請求，返回用戶登陸框頁面
3用戶在客戶端登陸
4服務器端將瀏覽器定位到callbackurl，并同時傳遞Authorization Code
5客戶端使用https發送access_token
6服務器端收到access_token請求，驗證Authorization Code---生成access_token, refresh_token,和過期時間--access_token和refresh_token和過期時間入庫
7 返回access_token和refresh_token,過期時間
8 用戶使用HTTPS+ access_token請求開放平臺接口
?
User-Agent:
適合所有無server端配合的客戶端
1客戶端http請求authorize
2服務端接收到authorize請求，返回用戶登陸框頁面
3用戶在客戶端登陸
4服務器端將瀏覽器定位到callbackurl，并同時傳遞access_token和過期時間
?
這里面的access_token可以考慮放在緩存中而不是放在數據庫中，一旦過期時間到就可以作廢了
?
Username and Password Flow
適合所有情況
1 客戶端https請求access_token（使用https是由于參數中帶著開心網的用戶名和密碼信息）2 服務器端收到access_token請求---生成access_token, refresh_token,和過期時間--access_token和refresh_token和過期時間入庫
3 json返回access_token, refresh_token,和過期時間
?
特別說明：
oauth2.0客戶端得到access_token之后是使用https來調用請求的，這樣做的目的主要是放重放和數據泄露?
?
參考文檔：
http://djb4ke.iteye.com/blog/683153
http://oauth.net/2/
http://hueniverse.com/2010/05/introducing-oauth-2-0/
http://wiki.open.kaixin001.com/index.php?id=OAuth2.0%E6%96%87%E6%A1%A3?
?
作者：軒脈刃(yjf512)?
出處：（http://www.cnblogs.com/yjf512/）?
版權聲明：本文的版權歸作者與博客園共有。歡迎轉載閱讀，轉載時須注明本文的詳細鏈接。?
總結
以上是生活随笔為你收集整理的开放平台_OAuth2.0的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Ubuntu 中安装 Oracle 10
- 下一篇： OpenBoard的板级支持包（BSP）