以前最煩的就是xx和我說你咋不支持OAuth啊？那是標準啊，多通用啊？同學，標準是啥？中國還有個饅頭標準，直徑大于多少還不算是饅頭呢！其實早在我做開放平臺時，OAuth的確實有了，但是當時也就是個草案，不過也是一群大牛公司的人在那兒搗鼓，但是當時沒有一個真正的開放平臺大牛公司的人在做這個（我認為雅虎系是當時最早一批做開放平臺的）。
前幾天在微博上發了三張OAuth2的手寫草稿（具體可以看看t.sina.com/fangweng），其實也是為了今天在內部產品和研發小范圍分享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規范而不知道規范為什麼這么設計，那么還是不要鼓吹什么標準。不然就和饅頭標準一樣，說出來也就是個笑話。