OAuth2.0這個名詞你是否在專案中時常聽到呢？是否覺得好像懂，又好像不太懂呢？

最近一直想寫篇關於OAuth2.0的東西，記錄下我的學習與感悟，然各種理由的拖延，直到今日才靜下心來寫下這篇部落格。當然，這裡僅代表個人理解，如有紕漏之處，望園內大佬們不吝賜教～

好了，話不多說，乾貨頂上。

幾個基本概念

認證（Authentication）和授權(Authorization)

在接觸OAuth2.0時是否常聽到認證和授權這兩個名詞呢？

剛接觸時，一直以為這兩個詞是一個意思，只是大家說法的不同而已。然，在看完官方開發文件後才知道，這根本就是兩個東西，不能混為一談。下面詳細說說：

• 認證：主要用於驗證身份。比如，我們進出火車站，身份證證明自己是張三而不是李四，這就是認證。
• 授權：主要用於判斷是否擁有相應的許可權。比如，我們進出火車站，火車票證明我們有乘坐列車的許可權，這就是授權。

現在看看，是不是挺簡單的概念，頓時清晰起來？

OAuth定義的四個角色

• 資源擁有者：受保護資源的擁有者，可以對他人授權，讓其訪問該資源。
• 資源伺服器：託管受保護資源的伺服器，只要認證和授權通過，便可響應該資源。
• 客戶端：提出請求受保護資源的應用程式。
• 授權伺服器：當認證和授權成功後，給客戶端釋出訪問令牌（access token）。

訪問令牌

訪問令牌，其實就是可以訪問受保護資源的一個憑證。一般而言，這是串加密過的字串，頒發給客戶端，用於替換使用者名稱和密碼，避免每次請求都攜帶使用者名稱密碼，增加安全風險。

協議流程

上面這張圖便是OAuth 2.0抽象的協議流程，描述了其定義的四個角色之間的互動關係。我將這個流程分為了前期準備和獲取資源兩個部分，詳細如下：

前期準備（這是一次性操作，可通過介面申請，與資源擁有者的使用者代理溝通等）：

• 客戶端向資源擁有者申請受保護資源的訪問許可權；
• 客戶端得到擁有者的授權，表示客戶端可以訪問該受保護資源。

獲取資源（Restful請求，每次訪問資源都得經過該操作）：

• 客戶端攜帶使用者名稱、密碼或clientId、secret等方式，向授權伺服器發起認證和授權；
• 授權通過，授權伺服器向客戶端返回訪問令牌(access token)；
• 客戶端攜帶訪問令牌，向資源伺服器訪問受保護資源；
• 資源伺服器驗證訪問令牌的有效性之後，向客戶端返回受保護資源。

授權

授權成功其實就是資源擁有者頒發的可以訪問受保護資源的憑證。當然客戶端直接拿著憑證是無法訪問資源的，還需拿著這個憑證去授權伺服器拿訪問令牌，憑著令牌便可直接訪問受保護資源。

OAuth 2.0官方給出的規範，授權的具體方式共有四種（可自定義）：資源擁有者密碼憑證，客戶端憑證，授權碼和隱式授權，；當然自定義機制也是支援的。

資源擁有者憑證授權

資源擁有者密碼憑證的授權方式僅適用於資源擁有者和客戶端高度信任的場景。

• 資源擁有者提供客戶端密碼憑證（resourId: secret)
• 客戶端攜帶密碼憑證直接去授權伺服器獲取訪問令牌

客戶端憑證授權

客戶端攜帶自身憑證（clientId: secret）直接去授權伺服器獲取訪問令牌

授權碼授權

一次性操作(授權碼只需要獲取一次即可)：

• 客戶端重定向URI和身份資訊直接訪問資源擁有者或者擁有者的使用者代理（一般為前端）
• 使用者代理拿著客戶端身份資訊和重定向URI，重定向至訪問授權伺服器；
• 授權伺服器對客戶端的資訊進行認證和授權；
• 認證和授權通過後，將授權碼返回至使用者代理；
• 使用者代理將授權碼返回給客戶端

獲取資源：

• 客戶端拿著授權碼和去授權伺服器獲取訪問令牌；
• 客戶端攜帶訪問令牌，向資源伺服器訪問受保護資源；
• 資源伺服器驗證訪問令牌的有效性之後，向客戶端返回受保護資源。

優勢：對客戶端進行認證；訪問令牌沒有直接返回至客戶端，所以沒有經歷第三方（使用者代理），減少暴露令牌的可能。

隱式授權

隱士授權是個簡化的授權流程，適用於前端頁面由指令碼語言（如Javascript）編寫的場景，對於React，Angular等編寫的前端，建議使用授權碼的授權方式。

• 客戶端攜帶身份資訊和重新向URI（一般為前端主介面地址）訪問使用者代理；
• 使用者代理將客戶端身份資訊和重定向URI發往授權伺服器，並進行使用者認證；
• 認證授權通過後，將訪問令牌拼進重定向URI，並將這個新的URI發往使用者代理；
• 使用者代理直接重定向至新的URI，載入主介面（所需資料，可根據訪問令牌去資源伺服器獲取）;
• 使用者代理將訪問令牌返回客戶端。

注意：一般隱式授權，可以利用重定向URI進行客戶端認證。

作者：吳家二少

部落格地址：https://www.cnblogs.com/cloudman-open/

本文歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文