我與OAuth 2.0那點荒唐的小祕密

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/

本文歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接