以前最煩的就是xx和我說你咋不支持OAuth啊？那是標(biāo)準(zhǔn)啊，多通用啊？同學(xué)，標(biāo)準(zhǔn)是啥？中國還有個饅頭標(biāo)準(zhǔn)，直徑大于多少還不算是饅頭呢！其實早在我做開放平臺時，OAuth的確實有了，但是當(dāng)時也就是個草案，不過也是一群大牛公司的人在那兒搗鼓，但是當(dāng)時沒有一個真正的開放平臺大牛公司的人在做這個（我認(rèn)為雅虎系是當(dāng)時最早一批做開放平臺的）。
前幾天在微博上發(fā)了三張OAuth2的手寫草稿（具體可以看看t.sina.com/fangweng），其實也是為了今天在內(nèi)部產(chǎn)品和研發(fā)小范圍分享OAuth2的優(yōu)勢，同時也對將來淘寶開放平臺授權(quán)從單應(yīng)用授權(quán)到將來多平臺互通做準(zhǔn)備。OAuth1我現(xiàn)在依舊保持自己的看法，沒覺得有什么優(yōu)勢在！但是，今天來看OAuth2的這些人（都是實實在在的做開放平臺的人）制定的標(biāo)準(zhǔn)，可以發(fā)現(xiàn)它的設(shè)計緣由和優(yōu)勢，這里不談OAuth2的流程，就說說幾個小變化，這幾個小變化直接決定了整個流程的差異化。
在OAuth2流程中有2個載體，3個過程，4個角色：
兩個載體：
Authorization Code， Access Token（refresh token）
三個過程：
用戶認(rèn)證，應(yīng)用認(rèn)證，用戶授權(quán)
四個角色：
用戶，應(yīng)用，授權(quán)服務(wù)器，資源服務(wù)器
第一個改變發(fā)生在角色的拆分：將授權(quán)服務(wù)器和資源服務(wù)器拆分開來。將授權(quán)與資源訪問的宿主由一一對應(yīng)變成了一對多的方式，只要資源訪問能夠驗證授權(quán)，那么任何授權(quán)服務(wù)點都可以成為該類資源的授權(quán)中心。其實也是為多種平臺間互聯(lián)互通技術(shù)的提供更靈活的支持，另一方面針對不同終端的授權(quán)也可以定制化流程，只要最終授權(quán)流程得到的結(jié)果可以被資源提供者所認(rèn)可就行。
第二個改變發(fā)生在獲取Access Token的過程，簡化了一次交換Token的流程。我至今還不是很清楚折騰反復(fù)那么多次交換的用處。
第三個，對于Agent和Client的模式有了更明確的流程支持。C/S模式和純JS模式都是沒有一個可以推送授權(quán)結(jié)果服務(wù)端的問題，現(xiàn)在流程中利用在URL參數(shù)中增加#在帶上業(yè)務(wù)參數(shù)不會被302從定向提交給服務(wù)端來解決安全性和數(shù)據(jù)獲取的問題。
第四個，提高開發(fā)者的授權(quán)開發(fā)門檻，降低開發(fā)服務(wù)請求門檻。可以想象的到授權(quán)本身的調(diào)用量和使用比例要遠(yuǎn)小于服務(wù)調(diào)用量。原先對于三個過程中的應(yīng)用認(rèn)證主要發(fā)生在服務(wù)調(diào)用中，每次調(diào)用都要對參數(shù)作簽名（由于參數(shù)的復(fù)雜性及調(diào)用次數(shù)很多，入口很多，導(dǎo)致開發(fā)查錯難），而現(xiàn)在應(yīng)用認(rèn)證和用戶授權(quán)都發(fā)生在授權(quán)流程中，完全剝離了資源訪問者對應(yīng)用認(rèn)證的處理，增加了授權(quán)開發(fā)成本，卻降低了服務(wù)調(diào)用成本。（其實這種設(shè)計大量被用在前后端設(shè)計優(yōu)化中）
另一些小細(xì)節(jié)也顯示出了這是開放平臺人做的標(biāo)準(zhǔn)：CSRF攻擊的預(yù)防（增加了State字段），允許應(yīng)用身份登陸（操作一些應(yīng)用相關(guān)的平臺型服務(wù)），scope來擴(kuò)展業(yè)務(wù)訪問控制范圍，expires time表示Token的有效期（原來都是無限長時間的）
同時電子商務(wù)網(wǎng)站與SNS網(wǎng)站還是在安全性上有些差異，同時服務(wù)的控制方面也有不同，因此在資源提供者這段也會有一些附加的控制策略在，通過OAuth2的一些擴(kuò)展點來更加細(xì)化控制。總的一句話：如果只知道Follow規(guī)范而不知道規(guī)范為什麼這么設(shè)計，那么還是不要鼓吹什么標(biāo)準(zhǔn)。不然就和饅頭標(biāo)準(zhǔn)一樣，說出來也就是個笑話。