Spring Cloud Security OAuth2.0 認證授權系列（一） 基礎概念

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

前序

最近想搞下基于Spring Cloud的認證授權平台，總體想法是可以對服務間授權，想做一個基于Agent 的無侵入的方式。

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

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

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

這次準備再從頭梳理下這方面的隻是，逐漸遞進。盡量不搞長篇大論，看的腦闊疼，争取一篇一個點的推進。

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

基礎概念

1、認證的概念

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

比如我們在使用抖音前都需要進行注冊吧，然後在輸入使用者名和密碼（或驗證碼）來登入賬号。

這裡登陸的過程就是 認證

那為什麼要認證？

認證，其實就是為了保護系統的資源，隻有使用者身份合法才可以通路資源。

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

息，身份合法方可繼續通路，不合法則拒絕通路。

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

• 使用者名密碼登入
• 二維碼登入
• 手機短信登入
• 指紋認證
• 人臉識别

2、會話的概念

大家想想，如果我使用微信每點一個按鈕都要我進行一次認證，那我豈不是要瘋了。是以為了避免這種問題，在使用者認證完成後可将使用者資訊儲存在會話中。

會話其實就是系統保留了目前使用者登入狀态所提供的一種機制。

常見的會話方式：

• 基于session
• 基于token

基于session的認證方式：

1、使用者認證成功，在服務端将使用者資訊儲存在session中（目前很多為redis）

2、将sesssion_id傳回給用戶端并存入 cookie 中

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

基于token的認證方式：

1、使用者認證成功，在服務端會根據使用者資訊和某種加密手段生産一個token（如JWT）發給用戶端

2、用戶端将token存入 cookie 或 localStorage 中，在每次請求時帶上token，服務端就可以根據token進行使用者身份認證。服務端無需進行token存儲，因為使用者資訊都包含在token中。

注意：

• session的認證方式由Servlet規範定制，服務端需存儲session，用戶端需要支援 cookie（如不支援cookie就需要特殊處理）
• token的認證方式不需要服務端存儲token，并且不限制用戶端的存儲方式
• 在現今的網際網路時代，系統多為前後端分離的架構設計，是以基于token的方式更好點

3、授權的概念

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

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

隻有綁定銀行卡的使用者才可以發紅包，也就是說此時的使用者擁有了發紅包的權限。

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

為什麼要授權？

認證是為了确認使用者的合法性，而授權是為了更細粒度的對資料進行劃分，授權是發生在認證完成後的，用來控制不同的使用者通路不同的資源。

授權： 授權是使用者認證通過根據使用者的權限來控制使用者通路資源的過程，擁有資源的通路權限則正常通路，沒有

權限則拒絕通路。

授權的資料模型

都知道寫代碼有設計模式，經過總結，授權也有其資料模型

其實也就是哪些使用者，擁有哪些權限，可以通路哪些資源，如下圖：

關于上圖，我們可以抽象出幾個關鍵點：

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 實作分布式認證授權