為什么需要oAuth

如果你接觸網絡的時間比較早，你應該能體會到網站注冊登錄方式的變化：

早期需要你輸入用戶名，密碼，然后要輸入郵箱，基于郵件來完成注冊驗證，然后使用用戶名密碼來登錄。因為當時郵箱是相對比較普及的。我當時在大學里學習計算機，老師布置的第一個任務就是去注冊個郵箱。
后來手機普及了，網站注冊登錄的方式是輸入手機號，收到驗證碼來驗證注冊登錄
再后來，可以直接基于微信、微博、QQ三方授權的方式來進行登錄

你會發現，注冊登錄的方式越來越簡單：

在早期你必須在每個你需要登陸的網站來注冊賬號密碼，相同的賬號密碼吧，怕被盜了一個密碼，其它全部被盜。不同的賬號密碼吧，記起來又費勁。后來出現了專門幫人管理密碼的軟件，不記得叫什么了。
使用手機號碼的方式，你可以基于驗證碼來進行臨時登錄，不過每次輸入驗證碼也挺麻煩的
三方授權的方式（也就是oAuth）只需要點擊確定授權，即可以登錄訪問，免去了注冊、驗證、再登陸的麻煩

可以看出，現在微信、微博、QQ這些用戶基數大的軟件，替代了當初的郵箱、手機，變成了注冊登錄的基礎設施。而且更加的安全：

同時你也不需要記一堆亂七八糟的密碼了，只需要記著微信、微博、QQ的賬號密碼就可以了。

另一方面，對開發者來說，也省去了對賬號體系的管理，只需要遵循oAuth規范來接入微信、微博、QQ即可，降低了開發成本。

了解了oAuth的作用，我們來看一看oAuth的實現。

oAuth的概念

前段時間閱文集團合同事件鬧得沸沸揚揚，其中一個主要的問題就是資源所屬問題，合同里規定作者寫的作品歸閱文集團所有！網友立馬就炸了，那作品到底歸作者所有還是閱文集團所有呢？oAuth協議里已經給出了答案。

oAuth定義了四個角色：

OAuth 2.0的運行流程如下圖：

假設我們要通過閱文來登錄一個第三方網站：

「資源擁有者」打開「網站」以后，該「網站」要求「資源擁有者」給予授權
「資源擁有者」同意「網站」授權，「網站」接收到授權憑證。這里的授權方式取決于「網站」請求方式以及「授權服務器」所支持的方式。oAuth2.0協議里定義了四種方式，包括：授權碼模式、簡化模式、密碼模式和客戶端模式，后面會具體說明。當然也可以自定義。
「網站」使用上一步獲得的授權，向「認證服務器」申請令牌
「認證服務器」對「網站」進行認證以后，確認無誤，同意發放令牌
「網站」使用令牌，向「資源服務器」申請獲取資源
「資源服務器」確認令牌無誤，同意向「網站」開放資源

流程里很明顯：

從上面的流程可以看出，整個流程中「三方網站」沒有獲取到用戶的任何敏感信息，且獲取的信息需要用戶主動授權后才能獲取到，保證了安全性和便利性。

下面來一個個的說明具體的授權模式。在開始之前，需要多理解幾個概念：

授權碼模式是功能最完整、流程最嚴密的授權模式。它通過Client的后臺服務器，與「服務提供商」的認證服務器進行互動置換token。具體流程如下：

更新令牌(RefreshToken)的作用下文說明

簡化模式不通過第三方應用程序的服務器，直接在瀏覽器中向認證服務器申請令牌，跳過了"授權碼"這個步驟。所有步驟在瀏覽器中完成，令牌對用戶是可見的，且客戶端不需要認證。具體流程如下：

「用戶」基于瀏覽器訪問「客戶端」，「客戶端」重定向到「認證服務器」對應頁面，引導的參數上會附帶一個「重定向URI」，指向的是「客戶端」頁
「用戶」選擇是否授權
授權后，「認證服務器」根據「重定向URI」將瀏覽器引導回「客戶端」頁，在URI的Fragment中會附帶訪問令牌
「客戶端」瀏覽器根據指令向「Web Hosted Client Resource」發送請求，該請求不包括上一步收到的Fragment，瀏覽器本地保存Fragment
「Web Hosted Client Resource」返回一個網頁（通常是一個包含腳本的網頁，如果你理解JSONP，應該比較容易理解），這段腳本是可以從Fragment中解析出訪問令牌的
瀏覽器執行腳本獲取令牌
瀏覽器將令牌發放給客戶端