Spring Cloud Security OAuth2.0 認證受權

世界上最快的捷徑，就是腳踏實地，本文已收錄【 架構技術專欄】關注這個喜歡分享的地方。

前序

最近想搞下基於Spring Cloud的認證受權平臺，整體想法是能夠對服務間受權，想作一個基於Agent 的無侵入的方式。

由於新版本的Spring Cloud Security 、 OAuth2.0 貌似改了些東西，說上網隨便翻翻，但發現沒有針對Spring Security OAuth2.0認證受權系統性的文章。

遂結合一些資料和本身的一些梳理，來搞一個認證受權系列，就當是一個總結了。

其實前面我也搞了幾個關於認證受權的文章，但總感受太零碎了，不成體系，沒搞過 Security 、OAuth2.0、JWT的人會一臉懵逼。

此次準備再從頭梳理下這方面的只是，逐步遞進。儘可能不搞長篇大論，看的腦闊疼，爭取一篇一個點的推動。

話很少說，飯要一口口吃，基礎的東西其實也很重要，那就從頭來講吧。

基礎概念

一、認證的概念

在這個移動時代，咱們天天都在各類APP間切換着，好比抖音、淘寶、微信等，好比咱們拿抖音來舉例說明認證的一些基礎概念。

好比咱們在使用抖音前都須要進行註冊吧，而後在輸入用戶名和密碼（或驗證碼）來登陸帳號。

這裏登錄的過程就是 認證

那爲何要認證？

認證，其實就是爲了保護系統的資源，只有用戶身份合法才能夠訪問資源。

認證 ：用戶認證就是判斷一個用戶的身份是否合法的過程，用戶去訪問系統資源時系統要求驗證用戶的身份信

息，身份合法方可繼續訪問，不合法則拒絕訪問。

常見的用戶身份認證方式有：

• 用戶名密碼登陸
• 二維碼登陸
• 手機短信登陸
• 指紋認證
• 人臉識別

二、會話的概念

你們想一想，若是我使用微信每點一個按鈕都要我進行一次認證，那我豈不是要瘋了。因此爲了不這種問題，在用戶認證完成後可將用戶信息保存在會話中。

會話其實就是系統保留了當前用戶登陸狀態所提供的一種機制。

常見的會話方式：

• 基於session
• 基於token

基於session的認證方式：

一、用戶認證成功，在服務端將用戶信息保存在session中（目前不少爲redis）

二、將sesssion_id返回給客戶端並存入 cookie 中

客戶端每次請求時帶上session_id，服務端就會根據其進行用戶合法性驗證。當用戶退出系統或session過時時，客戶端的session_id也就失效了。

基於token的認證方式：

一、用戶認證成功，在服務端會根據用戶信息和某種加密手段生產一個token（如JWT）發給客戶端

二、客戶端將token存入 cookie 或 localStorage 中，在每次請求時帶上token，服務端就能夠根據token進行用戶身份認證。服務端無需進行token存儲，由於用戶信息都包含在token中。

注意：

• session的認證方式由Servlet規範定製，服務端需存儲session，客戶端須要支持 cookie（如不支持cookie就須要特殊處理）
• token的認證方式不須要服務端存儲token，而且不限制客戶端的存儲方式
• 在現今的互聯網時代，系統多爲先後端分離的架構設計，因此基於token的方式更好點

三、受權的概念

咱們那微信來舉例，當用戶登錄成功後就可使用發朋友圈、添加好友、發紅包等功能。

但此時若是咱們沒有綁卡，是沒法使用發紅包功能的，也就是說咱們沒有發紅包的權限。

只有綁定銀行卡的用戶才能夠發紅包，也就是說此時的用戶擁有了發紅包的權限。

這個根據用戶的權限來控制用戶使用資源的過程就是受權 。

爲何要受權？

認證是爲了確認用戶的合法性，而受權是爲了更細粒度的對數據進行劃分，受權是發生在認證完成後的，用來控制不一樣的用戶訪問不一樣的資源。

受權： 受權是用戶認證經過根據用戶的權限來控制用戶訪問資源的過程，擁有資源的訪問權限則正常訪問，沒有

權限則拒絕訪問。

受權的數據模型

都知道寫代碼有設計模式，通過總結，受權也有其數據模型

其實也就是哪些用戶，擁有哪些權限，能夠訪問哪些資源，以下圖：

關於上圖，咱們能夠抽象出幾個關鍵點：

who 對what 進行 how 操做

who : 用戶

what: 資源

how: 權限

例如上面，用戶02 能夠對商品信息01 進行修改操做，其實這也是一種經典的受權方案，後面咱們再來細說

而後經過上圖，能夠抽象其中的關係，來幫助咱們落地數據庫表設計，來一個經典的：

受權方案

如何實現受權的設計？其實業界有幾種經常使用方案：

• ACL 訪問控制列表，表達和執行能力都較弱
• RBAC 基於角色的權限控制，表達能力有所欠缺，只能表達正向的訪問控制，反向控制較難
• ABAC 基於屬性的權限控制，能較好地表達反向訪問控制，但執行能力較差
• PBAC 基於策略的權限控制，結合了RBAC 和 ABAC 的最佳特性，它能實現更多應用場景複雜且靈活的管理控制需求

其中ABAC和PBAC在互聯網場景中不多使用，ACL是直接關係，RBAC是間接關係，因此咱們來看下通常經常使用的RBAC

RBAC

RBAC權限模型（Role-Based Access Control）, 基於角色的權限控制

在20世紀90年代期間，大量的專家學者和專門研究單位對RBAC的概念進行了深刻研究，前後提出了許多類型的RBAC模型，其中以美國George Mason大學信息安全技術實驗室（LIST）提出的RBAC96模型最具備系統性，獲得廣泛的公認。

RBAC認爲權限的過程能夠抽象歸納爲：判斷【Who是否能夠對What進行How的訪問操做】這個邏輯表達式的值是否爲True的求解過程。

RBAC模型的數據庫建模

RBAC 將權限問題轉換爲Who、What、How的問題，其實根本就是用戶經過角色進行權限關聯。

一個用戶能夠擁有多個角色，一個角色又能夠擁有多個權限。這樣就構成了用戶 - 角色 - 權限的受權模型。在模型中，用戶和角色之間，角色和權限之間，通常是多對多關係，如圖。

這裏有個核心點，就是角色，能夠理解爲權限的集合體，是一種載體。好比論壇的版主、超級管理員等，版主能夠管理對帖子進行管理，這就是權限。若是要給某個用戶授予這些權限，只須要把角色賦予該用戶就行了，而不須要和權限進行直接綁定。

進一步，增長權限組設計

而在實際應用過程當中會發現，當用戶量很是大的時候，若是咱們要給每一個用戶進行受權那真是累到手抽筋啊。因此，這時候就須要給用戶分組，分組後咱們也能夠直接給用戶組進行受權。這時用戶所擁有的權限，就是用戶我的權限和用戶組權限之和。

咱們來看看進化後的模型：

再進一步，增長頁面功能權限設計

在咱們實現場景中，對功能模塊的操做、菜單訪問、按鈕訪問、文件上傳等均可屬於權限的範疇。

在有些權限設計中，會把功能操做做爲一類，而把文件、菜單、頁面元素等做爲另外一類，這樣構成「用戶-角色-權限-資源」的受權模型。

在作數據表建模時，可把功能操做和資源統一管理，也就是都直接與權限表進行關聯，這樣可能更具便捷性和易擴展性

好比這裏咱們有菜單、文件等功能，咱們來看下權限表更新後的設計：

這裏有幾個核心點說一下：

經過權限表的權限類型字段，咱們能夠自有擴展本身的權限。好比MENU表明菜單權限、FILE表明文件權限，咱們在擴展時只須要建一張權限XXX關聯表就能夠了。

這裏權限表、菜單表、權限菜單關聯表是1對1的關係，因此若是新增一個菜單就須要同時在三張表內插入記錄。在設計時也能夠省去關聯表，直接叫權限表和菜單表進行關聯，只是須要在權限表內增長一個記錄菜單ID的字段，方便後面進行區分。

好了，到目前爲止，基於RBAC的權限模型設計就完成了，來一個完整的設計圖

後序

本章節屬於針對於基礎概念作了些鋪墊，RBAC屬於重點內容，也屬於咱們目前設計權限也會常常用到的一種模式。

至於RBAC的表設計，其實萬變不離其宗，主要的仍是搞清楚who、what、how。至於具體怎麼實現就看你的業務需求了，沒有完美的設計，只有不停的迭代。

後續計劃，大概說下

• Spring Cloud Security 使用
• 和OAuth2.0怎麼結合
• 分佈式系統的認證方案
• 基於Spring CloudSecurity 實現分佈式認證受權