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/
本文歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接