基於oAuth的受權登陸

爲何須要oAuth

若是你接觸網絡的時間比較早，你應該能體會到網站註冊登陸方式的變化：

• 早期須要你輸入用戶名，密碼，而後要輸入郵箱，基於郵件來完成註冊驗證，而後使用用戶名密碼來登陸。由於當時郵箱是相對比較普及的。我當時在大學裏學習計算機，老師佈置的第一個任務就是去註冊個郵箱。
• 後來手機普及了，網站註冊登陸的方式是輸入手機號，收到驗證碼來驗證註冊登陸
• 再後來，能夠直接基於微信、微博、QQ三方受權的方式來進行登陸

你會發現，註冊登陸的方式愈來愈簡單：

• 在早期你必須在每一個你須要登錄的網站來註冊帳號密碼，相同的帳號密碼吧，怕被盜了一個密碼，其它所有被盜。不一樣的帳號密碼吧，記起來又費勁。後來出現了專門幫人管理密碼的軟件，不記得叫什麼了。
• 使用手機號碼的方式，你能夠基於驗證碼來進行臨時登陸，不過每次輸入驗證碼也挺麻煩的
• 三方受權的方式（也就是oAuth）只須要點擊肯定受權，便可以登陸訪問，免去了註冊、驗證、再登錄的麻煩

能夠看出，如今微信、微博、QQ這些用戶基數大的軟件，替代了當初的郵箱、手機，變成了註冊登陸的基礎設施。並且更加的安全：

• 經過郵箱註冊，假設你訪問了一些不正經的網站，郵箱被泄露後，會收到一堆垃圾郵件
• 經過手機號註冊，手機號被泄露後，會收到一堆的騷擾電話
• 而oAuth不會存在泄露的問題，除非微信、微博、QQ泄露了你的信息！

同時你也不須要記一堆亂七八糟的密碼了，只須要記着微信、微博、QQ的帳號密碼就能夠了。

另外一方面，對開發者來講，也省去了對帳號體系的管理，只須要遵循oAuth規範來接入微信、微博、QQ便可，下降了開發成本。

瞭解了oAuth的做用，咱們來看一看oAuth的實現。

oAuth的概念

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

oAuth定義了四個角色：

• 資源擁有者（resource owner）：絕大部分狀況下，指的是用戶。

• 資源服務器（resource server）：指的是服務提供商用來提供服務的服務器。

• 客戶端（client）：即三方應用，須要用戶來受權訪問的應用

• 受權服務器（authorization server）：即服務提供商專門用來處理受權認證的服務器。

OAuth 2.0的運行流程以下圖：

假設咱們要經過閱文來登陸一個第三方網站：

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

流程裏很明顯：

• 「網站」就是Client

• 「認證服務器」就是AuthorizationServer，屬於閱文

• 「資源服務器」就是ResourceServer，也屬於閱文

• 而「資源擁有者」指的就是用戶。你用閱文集團來替換「資源擁有者」，就會發現流程明顯有問題。

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

oAuth的分類

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

• User-Agent：用戶代理，絕大部分狀況下能夠直接理解爲瀏覽器

• Web Hosted Client Resource：網絡託管的客戶端資源，這裏能夠理解爲託管網絡腳本的服務器

受權碼模式（Authorization Code Grant）

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

• 「用戶」基於瀏覽器訪問「客戶端」，「客戶端」重定向到「認證服務器」對應頁面，引導的參數上會附帶一個「重定向URI」，指向的是「客戶端」頁

• 「用戶」選擇是否受權

• 受權後，「認證服務器」根據「重定向URI」將瀏覽器引導回「客戶端」頁，同時會附帶一個受權碼

• 「客戶端」接收到受權碼後，經過後臺服務器，攜帶這個受權碼以及「重定向URL」，向「認證服務器」申請令牌

• 「認證服務器」校驗無誤後，向「客戶端」發送令牌（AccessToken）和更新令牌（RefreshToken）

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

簡化模式（Implicit Grant）

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

• 「用戶」基於瀏覽器訪問「客戶端」，「客戶端」重定向到「認證服務器」對應頁面，引導的參數上會附帶一個「重定向URI」，指向的是「客戶端」頁

• 「用戶」選擇是否受權

• 受權後，「認證服務器」根據「重定向URI」將瀏覽器引導回「客戶端」頁，在URI的Fragment中會附帶訪問令牌

• 「客戶端」瀏覽器根據指令向「Web Hosted Client Resource」發送請求，該請求不包括上一步收到的Fragment，瀏覽器本地保存Fragment

• 「Web Hosted Client Resource」返回一個網頁（一般是一個包含腳本的網頁，若是你理解JSONP，應該比較容易理解），這段腳本是能夠從Fragment中解析出訪問令牌的

• 瀏覽器執行腳本獲取令牌

• 瀏覽器將令牌發放給客戶端

密碼模式（Resource Owner Password Credentials Grant）

相對於上面兩種受權模式，密碼模式相對的不安全，由於用戶須要向客戶端提供本身的用戶名和密碼。客戶端使用這些信息，向"服務商提供商"索要受權。雖然協議裏規定客戶端不能存儲帳號密碼，不過除非你很是信任客戶端，不然應該不會使用這種模式。

這種受權模式的具體流程以下：

• 「用戶」向「客戶端」提供用戶名和密碼

• 「客戶端」將用戶名和密碼發送給「認證服務器」，請求令牌

• 「認證服務器」驗證後，返回訪問令牌

客戶端模式（Client Credentials Grant）

客戶端模式下，用戶直接向客戶端註冊，客戶端以本身的名義要求"服務提供商"提供服務。具體流程以下：

• 「客戶端」向「認證服務器」進行身份認證，並要求一個訪問令牌

• 「認證服務器」驗證後，返回訪問令牌

更新令牌

在上面的流程中，認證服務器認證後返回的數據，除了訪問令牌，還有一個更新令牌。咱們知道了，經過訪問令牌咱們纔可以訪問資源，那更新令牌是作什麼用的呢？

咱們都知道，通常網站登陸會有一個超時時間，這裏也不例外。訪問令牌也有一個超時時間。更新令牌就是用於在訪問令牌過時後來獲取新的訪問令牌的。

• 「客戶端」向「受權服務器」進行認證，獲取access token。

• 「受權服務器」驗證「客戶端」後，發放訪問令牌和刷新令牌。

• 「客戶端」攜帶訪問令牌向「資源服務器」請求資源

• 「資源服務器」驗證訪問令牌，若是有效，則提供服務。

• 重複步驟3和4直到訪問令牌到期

• 當訪問令牌無效，「資源服務器」返回無效的令牌錯誤

• 「客戶端」向受權服務器進行身份驗證，並攜帶刷新令牌來請求新的訪問令牌

• 「受權服務器」驗證「客戶端」身份以及刷新令牌，若是有效，則發出新的訪問令牌（以及可選的新刷新令牌）

最後補充

在上面的流程中，實際還缺乏了一步，就是註冊客戶端。若是你接過微信、微博或QQ的受權登錄，那麼應該清楚，在開始接入以前，咱們須要在他們的開放平臺上申請咱們的應用，申請成功後會給咱們一個appId和一個appSecrect。

這個的appId就是用來惟一肯定客戶端的。而appSecrect就是在受權模式中，客戶端的後臺與受權服務器交互時須要連同code，appId一塊兒提供的，用於置換訪問令牌的。

總結

本文解釋了oAuth的做用，並梳理了oAuth的具體流程。

參考文檔

• 《The OAuth 2.0 Authorization Framework》www.ietf.org/rfc/rfc6749…

公號：抽象思惟