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截止到2011/8/31 為止已經發布更新了20個版本，下面是oauth2.0的ietf標準文件：
oauth2.0得到了越來越多大公司的支援，比如microsoft，yahoo等，也在實際使用過程中不斷得到優化和完善，oauth2.0已經成為了業界通用和使用的標準。
oauth2.0有許多種流程，分別適應不同的第三方應用，並且這些流程數目還在不斷增加和完善中，乙個**可以實現一種或多種流程
比如最典型的6中流程有 :
user-agent flow 客戶端執行於使用者**內（典型如web瀏覽器）。
web server flow 客戶端是web伺服器程式的一部分，通過
接入，這是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
三種方式
oauth2.0的客戶端實現是非常方便的，開心網的說明文件也已經非常全了，這裡就不多說了
下面說一下各個流程的步驟：
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請求開放平台介面
適合所有無server端配合的客戶端
1客戶端http請求authorize
2服務端接收到authorize請求，返回使用者登陸框頁面
3使用者在客戶端登陸
4伺服器端將瀏覽器定位到callbackurl，並同時傳遞access_token和過期時間
這裡面的access_token可以考慮放在快取中而不是放在資料庫中，一旦過期時間到就可以作廢了
適合所有情況
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來呼叫請求的，這樣做的目的主要是放重放和資料洩露
參考文件：
開放平台 OAuth2 0
1 oauth1.0對手機客戶端，移動裝置等非server第三方的支援不好。其實oauth1.0也是可以支援手機客戶端，移動裝置等，也有相應的流程。但是oauth1.0是將多種流程合併成了一種，而事實證明，這種合併的流程體驗性非常差 2 oauth1.0的三步認證過程比較繁瑣和複雜，對第三方開發者增...
關於開放平台的OAuth2 0認證
我是通過點點網了解到oauth2.0的，點點網關於oauth的介紹是 oauth 2.0是在2006年設計的oauth協議的下乙個版本,2.0版本更注重於客戶端開發的簡易性,同時給web,桌面,移動等平台給予支援,它是基於oauth wrap開放的一套安全認證的流程。a 客戶端發起授權請求 b 資源...
OAuth2 0新浪微博開放平台 騰訊社群開放平台
準備功夫 授權 我方引導客人到第三方平台確認授權。確認後，第三方平台向我方傳送即時確認資訊 附帶乙個臨時令牌 我方獲取到資訊之後，即時向第三方平台申請客人在我方對應的身份id 始終唯一 和服務密碼 有時限 這個身份id和服務密碼跟客戶在第三方平台上的id和密碼是不同的內容。儲存好資料後，授權過程就算...