經常會在一些推文中看到一個概念OAuth2.0，這個出現頻率還挺高的，這一篇博客就來簡單介紹一下下這是個啥。Tips:只涉及一些概念。
OAuth2.0是個啥?
先說OAuth，OAuth是Open Authorization的簡寫。
OAuth協議爲用戶資源的授權提供了一個安全的、開放而又簡易的標準。
簡單來說，它是一個協議，而本文的主角則是在OAuth的基礎上的一個延續版本—OAuth2.0協議。但不向前兼容(即完全廢止了OAuth1.0)。
那麼這個協議具體幹了些什麼呢?
有一句話形容它，“可以使一個系統經過授權後可以直接訪問另外一個系統”。 咋一聽，有點像之前博客介紹過的單點登錄(SSO),但是它們兩可是不一樣。
使用場景
這裏介紹一個學習時，老師舉例的場景：
假設，A網站是一個打印照片的網站，B網站是一個存儲照片的網站，二者原本毫無關聯。
如果一個用戶想使用A網站打印自己存儲在B網站的照片，那麼A網站就需要使用B網站的照片資源纔行。
按照傳統的思考模式，我們需要A網站具有登錄B網站的用戶名和密碼纔行，但是，現在有了OAuth2，只需要A網站獲取到使用B網站照片資源的一個通行令牌即可！這個令牌無需具備操作B網站所有資源的權限，也無需永久有效，只要滿足A網站打印照片需求即可。
這麼聽來，是不是有點像單點登錄？NONONO！千萬不要混淆概念！單點登錄是用戶一次登錄，自己可以操作其他關聯的服務資源。OAuth2則是用戶給一個系統授權，可以直接操作其他系統資源的一種方式。
但SpringSecurity的OAuth2也是可以實現單點登錄的！
總結一句：SpringSecurity的OAuth2可以做服務之間資源共享，也可以實現單點登錄！
OAuth2.0中四種授權方式
這裏還是上文舉到的例子,放一張圖：
授權碼模式（authorization code）
-
流程
說明：【A服務客戶端】需要用到【B服務資源服務】中的資源
第一步：【A服務客戶端】將用戶自動導航到【B服務認證服務】，這一步用戶需要提供一個回調地址，以備【B服務認證服務】返回授權碼使用。
第二步：用戶點擊授權按鈕表示讓【A服務客戶端】使用【B服務資源服務】，這一步需要用戶登錄B服務，也就是說用戶要事先具有B服務的使用權限。
第三步：【B服務認證服務】生成授權碼，授權碼將通過第一步提供的回調地址，返回給【A服務客戶端】。
注意這個授權碼並非通行【B服務資源服務】的通行憑證。
第四步：【A服務認證服務】攜帶上一步得到的授權碼向【B服務認證服務】發送請求，獲取通行憑證token。
第五步：【B服務認證服務】給【A服務認證服務】返回令牌token和更新令牌refresh token。
-
使用場景
授權碼模式是OAuth2中最安全最完善的一種模式，應用場景最廣泛，可以實現服務之間的調用，常見的微
信，QQ等第三方登錄也可採用這種方式實現。
簡化模式（implicit）
- 流程
說明：簡化模式中沒有【A服務認證服務】這一部分，全部有【A服務客戶端】與B服務交互，整個過程不再有授權碼，token直接暴露在瀏覽器。
第一步：【A服務客戶端】將用戶自動導航到【B服務認證服務】，這一步用戶需要提供一個回調地址，以備【B服務認證服務】返回token使用，還會攜帶一個【A服務客戶端】的狀態標識state。
第二步：用戶點擊授權按鈕表示讓【A服務客戶端】使用【B服務資源服務】，這一步需要用戶登錄B服務，也就是說用戶要事先具有B服務的使用權限。
第三步：【B服務認證服務】生成通行令牌token，token將通過第一步提供的回調地址，返回給【A服務客戶端】。
- 使用場景
適用於A服務沒有服務器的情況。比如：純手機小程序，JavaScript語言實現的網頁插件等。
密碼模式（resource owner password credentials）
-
流程
第一步：直接告訴【A服務客戶端】自己的【B服務認證服務】的用戶名和密碼
第二步：【A服務客戶端】攜帶【B服務認證服務】的用戶名和密碼向【B服務認證服務】發起請求獲取
token。第三步：【B服務認證服務】給【A服務客戶端】頒發token。
使用場景此種模式雖然簡單，但是用戶將B服務的用戶名和密碼暴露給了A服務，需要兩個服務信任度非常高才能使用。
客戶端模式（client credentials）
-
流程
說明：這種模式其實已經不太屬於OAuth2的範疇了。A服務完全脫離用戶，以自己的身份去向B服務索取token。換言之，用戶無需具備B服務的使用權也可以。完全是A服務與B服務內部的交互，與用戶無關了。
第一步：A服務向B服務索取token。
第二步：B服務返回token給A服務。
-
使用場景
A服務本身需要B服務資源，與用戶無關。
OAuth2.0扮演的角色
介紹完了OAuth2.0的四種模式，但是OAuth2.0在其中扮演的是什麼角色呢?
這裏有一張圖:
之前我們介紹的授權碼模式中,負責頒發token就是OAuth2.0的服務端，而當A系統拿到授權碼時，可以訪問到B系統的資源稱爲OAuth2.0的資源端。
在這之前，A系統需要得到B系統的訪問許可，怎麼得到呢?
這裏有兩種方式。一個是在B系統的內存中保存A系統的訪問許可，另外一個是在數據庫中。想一想都知道，現在開發還是數據庫中比較多。假設我們要做一個微信登錄，那麼微信應該會提供一個接口給我們，我們調用該接口後，就往微信的某張數據庫表裏保存了微信對我們的登錄許可，之後就可以直接用微信登錄了。而如果在內存中的話，每一次新增一個許可，就要去手動改對應代碼，特別麻煩…
而這個數據庫表其實Security已經幫我們規定好了，就像之前持久化token一樣，規定好了表名和表的字段，只需要去官網執行對應的腳本即可。
今天關於OAuth2.0的一些概念先介紹到這裏，感謝觀看🙏