講道理，Security是目前知道的框架中最難掌握的一個框架，我接下來的學習目標都將圍繞它而展開，
1.用戶認證
1.1 : 用戶認證與授權
用戶認證
-
當用戶去訪問我們的系統資源的時候，我們的系統需要驗證用戶的身份（比如賬號和密碼認證這是一種方式），如果身份合法則認證通過，頒發相應的免死金牌，如果驗證沒通過，則提示用戶請三思而后行，這就是用戶認證
用戶授權
-
用戶授權一般是與用戶認證相輔相成的，在認證的時候，如果認證通過，我們還會將該用戶的權限信息給收集起來，並將相應信息作為依據，封裝在認證的響應體中（JWT），當用戶認證成功后，訪問我們系統的某一個模塊的時候，該模塊是需要判斷該用戶是否有權訪問，如果沒有訪問該資源的訪問權限，用戶也只有被拒絕訪問，這就是用戶授權
1.2 : 單點登陸問題 SSO
單點登陸
-
單點登陸一般常見於分布式項目中，用戶只需要登陸一次，即認證一次，即可訪問分布式項目中的所有模塊，而不需要每訪問一個模塊就得去登陸認證一次，這樣用戶嫌麻煩，后端認證邏輯也冗余
1.3 : 第三方登陸
比如目前互聯網運用中的微信登陸、微博登陸、支付寶登陸等
-
用戶通過授權，第三方應用給予我們系統訪問他微信相關信息的權限，我們獲取后進行注冊，使其稱為我們系統的注冊人員，實現第三方登陸
2.關於Oauth2認證
2.1 : 認識Oauth2
Oauth2我認為是一種認證與授權的思想，我們可以將其運用在項目中，成為我們項目認證和授權的解決方案
首先Oauth2中有以下幾個角色： <我們就以微信登陸為列>
客戶端
-
就假如是我們自己的系統吧，這個客戶端和Oauth2不沾親帶故，可以是任何獨立的系統，比如我們的某個系統，或者某個app客戶端又或者是我們的系統web客戶端
資源擁有者
-
就是指我們的用戶，比如微信登錄中，在面對微信的數據庫時，我們的系統就是無關人員，而登陸的用戶，在微信的系統中就是該用戶信息的資源擁有者，他掌握着是否將他的微信個人信息暴露給我們的系統
授權服務器
-
在微信登陸中，就是用來辨別用戶的認證是否正確，是否可以成為該微信用戶信息的資源擁有者，在微信登陸中，該系統由微信系統提供，用於鑒別資源擁有者的身份合法性
資源服務器
-
這個就很簡單了，守護該微信用戶信息的服務器，他掌握着微信的用戶信息，我們的客戶端最后就是向他發起請求，想面對甲方一樣，求着他給我們響應該用戶的微信個人信息。
2.2 : Oauth2實現之三方登陸流程
接着上面的我們繼續加固我們對Oauth2的認識，下面我們就以微信登陸為列子，來說說Oauth2的運用實現，已經一般在項目中，Oauth2這種思想可以幫我們解決哪些問題
-
首先用戶，登陸我們的客戶端，點擊微信登陸
-
系統請求微信的授權系統，響應一個二維碼給用戶，用戶掃碼后點擊同意
-
微信的授權服務器會對該微信用戶進行驗證
-
驗證通過后，返回一個詢問頁面，是否授權給某某系統
-
用戶點擊確認，認證服務就會頒發一個授權碼給客戶端，並重定向我們的系統
-
-
此時我們的客戶端獲得授權碼，根據授權碼去微信的認證服務申請令牌
-
微信的認證服務器認證通過后，會頒發一個令牌給我們的系統
-
當系統拿到令牌時，也就是微信登陸成功之時
-
該令牌代表着我們的系統，有權訪問該微信用戶在微信中的個人信息數據
-
-
我們的客戶端攜帶令牌去微信的資源服務器獲取該微信用戶的個人信息
-
微信資源服務器校驗該令牌的合法性，通過后響應該用戶的微信個人信息數據給我們的客戶端
整體流程如下所示
2.3 : Oauth2的運用
思想在上面已經說明的還算通透了，總結以下，受保護的資源需要某種標識，這個標識可以用戶自己攜帶而來的（自己系統），也可以是外來系統在用戶授權后帶來的（外來系統），只要該標識驗證通過，則資源訪問放行，對外暴露請求接口，所以Oauth2的主要運用就是
-
保護某個資源只有在通過授權的情況下，才運行被請求
-
第三方登陸流程是一個列子
-
我們假如做大做強，我們的系統服務也可以通過上面的方式暴露給外來系統某些受保護的數據
-
本系統前端訪問后端資源，也可以解決一個授權問題
-
再其次就是我們系統服務之間的相互調用，當然這個做的就有點嚴謹了，但是思想是這個思想
-
Spring Security + Oauth2：認證授權方案
-
用戶攜帶賬號密碼 (或者三方登陸 )請求認證服務等，請求用戶認證
-
認證通過后，頒發身份令牌可客戶端，並將身份令牌儲存在Redis中
-
用戶攜帶身份令牌請求資源服務，必經網關
-
網關獲取客戶端帶來的令牌和Redis中的令牌進行比對校驗
-
校驗通過，服務轉發，資源服務器獲取到令牌，根據令牌完成授權
-
資源服務通過授權后響應數據給客戶端