以前最煩的就是
xx和我說你咋不支援
oauth
啊？那是標準啊，多通用啊？同學，標準是啥？中國還有個饅頭標準，直徑大於多少還不算是饅頭呢！其實早在我做開放平台時，
oauth
的確實有了，但是當時也就是個草案，不過也是一群大牛公司的人在那兒搗鼓，但是當時沒有乙個真正的開放平台大牛公司的人在做這個（我認為雅虎系是當時最早一批做開放平台的）。
前幾天在微博上發了三張
oauth2
的手寫草稿（具體可以看看
），其實也是為了今天在內部產品和研發小範圍分享
oauth2
的優勢，同時也對將來**開放平台授權從單應用授權到將來多平台互通做準備。
oauth1
我現在依舊保持自己的看法，沒覺得有什麼優勢在！但是，今天來看
oauth2
的這些人（都是實實在在的做開放平台的人）制定的標準，可以發現它的設計緣由和優勢，這裡不談
oauth2
的流程，就說說幾個小變化，這幾個小變化直接決定了整個流程的差異化。 在
oauth2
流程中有
2個載體，
3個過程，
4個角色：
兩個載體：
authorization code
，access token
（refresh token）
三個過程：
使用者認證，應用認證，使用者授權
四個角色：
使用者，應用，授權伺服器，資源伺服器
第乙個改變發生在角色的拆分：將授權伺服器和資源伺服器拆分開來。將授權與資源訪問的宿主由一一對應變成了一對多的方式，只要資源訪問能夠驗證授權，那麼任何授權服務點都可以成為該類資源的授權中心。其實也是為多種平台間互聯互通技術的提供更靈活的支援，另一方面針對不同終端的授權也可以定製化流程，只要最終授權流程得到的結果可以被資源提供者所認可就行。
第二個改變發生在獲取
access token
的過程，簡化了一次交換
token
的流程。我至今還不是很清楚折騰反覆那麼多次交換的用處。
第三個，對於
agent
和client
的模式有了更明確的流程支援。
c/s模式和純
js模式都是沒有乙個可以推送授權結果服務端的問題，現在流程中利用在
url引數中增加
#在帶上業務引數不會被
302從定向提交給服務端來解決安全性和資料獲取的問題。
第四個，提高開發者的授權開發門檻，降低開發服務請求門檻。可以想象的到授權本身的呼叫量和使用比例要遠小於服務呼叫量。原先對於三個過程中的應用認證主要發生在服務呼叫中，每次呼叫都要對引數作簽名（由於引數的複雜性及呼叫次數很多，入口很多，導致開發查錯難），而現在應用認證和使用者授權都發生在授權流程中，完全剝離了資源訪問者對應用認證的處理，增加了授權開發成本，卻降低了服務呼叫成本。（其實這種設計大量被用在前後端設計優化中）
另一些小細節也顯示出了這是開放平台人做的標準：
csrf
攻擊的預防（增加了
state
字段），允許應用身份登陸（操作一些應用相關的平台型服務），
scope
來擴充套件業務訪問控制範圍，
expires time
表示token
的有效期（原來都是無限長時間的）
同時電子商務**與
sns**還是在安全性上有些差異，同時服務的控制方面也有不同，因此在資源提供者這段也會有一些附加的控制策略在，通過
oauth2
的一些擴充套件點來更加細化控制。總的一句話：如果只知道
follow
規範而不知道規範為什麼這麼設計，那麼還是不要鼓吹什麼標準。不然就和饅頭標準一樣，說出來也就是個笑話。
OAuth2的一些改變
以前最煩的就是xx和我說你咋不支援oauth啊？那是標準啊，多通用啊？同學，標準是啥？中國還有個饅頭標準，直徑大於多少還不算是饅頭呢！其實早在我做開放平台時，oauth的確實有了，但是當時也就是個草案，不過也是一群大牛公司的人在那兒搗鼓，但是當時沒有乙個真正的開放平台大牛公司的人在做這個 我認為雅虎...
OAuth2與sso的結合思路
首次登入 1 使用者訪問a系統，a系統檢查自身的session 第三方系統概念，非統一認證中心概念 發現此人未登入，轉到統一認證中心登入檢查介面。2 統一認證中心檢查介面，判斷下sso domain下是否存在 access token，沒有表示需要進行首次登入驗證。3 跳轉到登入頁面，要求輸入使用者...
基於OAUTH2的統一認證的例項解析
sso與多平台登入 sso一般用於同一單位的多個站點的登陸狀態保持，技術上一般參考cas協議 多平台登入一般是oauth體系的協議，有多種認證模式但是不具備會話管理和狀態保持。不過從本質上講，我覺得兩者都是通過可信的第三方進行身份驗證，如果說同一單位的多個子系統共同只圍繞乙個第三方賬戶 可以稱為認證...