Spring Cloud Security OAuth2.0 认证授权系列（一）基础概念

冷不防 2022-12-23 06:51 251阅读 0赞

> 世界上最快的捷径，就是脚踏实地，本文已收录【[架构技术专栏][Link 1]】关注这个喜欢分享的地方。

## 前序 ##

最近想搞下基于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也就失效了。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center]

**基于token的认证方式：**

1、用户认证成功，在服务端会根据用户信息和某种加密手段生产一个token（如JWT）发给客户端

2、客户端将token存入 cookie 或 localStorage 中，在每次请求时带上token，服务端就可以根据token进行用户身份认证。服务端无需进行token存储，因为用户信息都包含在token中。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 1]

**注意：**

*  session的认证方式由Servlet规范定制，服务端需存储session，客户端需要支持 cookie（如不支持cookie就需要特殊处理）
 *  token的认证方式不需要服务端存储token，并且不限制客户端的存储方式
 *  在现今的互联网时代，系统多为前后端分离的架构设计，所以基于token的方式更好点

### **3、授权的概念** ###

我们那微信来举例，当用户登陆成功后就可以使用发朋友圈、添加好友、发红包等功能。

但此时如果我们没有绑卡，是无法使用发红包功能的，也就是说我们没有发红包的权限。

只有绑定银行卡的用户才可以发红包，也就是说此时的用户拥有了发红包的权限。

这个根据用户的权限来控制用户使用资源的过程就是授权 。

\*\*为什么要授权？ \*\*

认证是为了确认用户的合法性，而授权是为了更细粒度的对数据进行划分，授权是发生在认证完成后的，用来控制不同的用户访问不同的资源。

**授权**： 授权是用户认证通过根据用户的权限来控制用户访问资源的过程，拥有资源的访问权限则正常访问，没有

权限则拒绝访问。

**授权的数据模型**

都知道写代码有设计模式，经过总结，授权也有其数据模型

其实也就是哪些用户，拥有哪些权限，可以访问哪些资源，如下图：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 2]

关于上图，我们可以抽象出几个关键点：

who 对what 进行 how 操作

who : 用户

what: 资源

how: 权限

例如上面，用户02 可以对商品信息01 进行修改操作，其实这也是一种经典的授权方案，后面我们再来细说

然后通过上图，可以抽象其中的关系，来帮助我们落地数据库表设计，来一个经典的：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 3]

## 授权方案 ##

如何实现授权的设计？其实业界有几种常用方案：

*  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的问题，其实根本就是用户通过角色进行权限关联。

一个用户可以拥有多个角色，一个角色又可以拥有多个权限。这样就构成了用户 - 角色 - 权限的授权模型。在模型中，用户和角色之间，角色和权限之间，一般是多对多关系，如图。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 4]

这里有个核心点，就是角色，可以理解为权限的集合体，是一种载体。比如论坛的版主、超级管理员等，版主可以管理对帖子进行管理，这就是权限。如果要给某个用户授予这些权限，只需要把角色赋予该用户就好了，而不需要和权限进行直接绑定。

**进一步，增加权限组设计**

而在实际应用过程中会发现，当用户量非常大的时候，如果我们要给每个用户进行授权那真是累到手抽筋啊。所以，这时候就需要给用户分组，分组后我们也可以直接给用户组进行授权。这时用户所拥有的权限，就是用户个人权限和用户组权限之和。

我们来看看进化后的模型：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 5]

**再进一步，增加页面功能权限设计**

在我们实现场景中，对功能模块的操作、菜单访问、按钮访问、文件上传等都可属于权限的范畴。

在有些权限设计中，会把功能操作作为一类，而把文件、菜单、页面元素等作为另一类，这样构成“用户-角色-权限-资源”的授权模型。

在做数据表建模时，可把功能操作和资源统一管理，也就是都直接与权限表进行关联，这样可能更具便捷性和易扩展性

比如这里我们有菜单、文件等功能，我们来看下权限表更新后的设计：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 6]

这里有几个核心点说一下：

通过权限表的权限类型字段，我们可以自有扩展自己的权限。比如`MENU`代表菜单权限、`FILE`代表文件权限，我们在扩展时只需要建一张权限XXX关联表就可以了。

这里权限表、菜单表、权限菜单关联表是1对1的关系，所以如果新增一个菜单就需要同时在三张表内插入记录。在设计时也可以省去关联表，直接叫权限表和菜单表进行关联，只是需要在权限表内增加一个记录菜单ID的字段，方便后面进行区分。

好了，到目前为止，基于RBAC的权限模型设计就完成了，来一个完整的设计图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 7]

## 后序 ##

本章节属于针对于基础概念做了些铺垫，RBAC属于重点内容，也属于我们目前设计权限也会经常用到的一种模式。

至于RBAC的表设计，其实万变不离其宗，主要的还是搞清楚who、what、how。至于具体怎么实现就看你的业务需求了，没有完美的设计，只有不停的迭代。

后续计划，大概说下

*  Spring Cloud Security 使用
 *  和OAuth2.0怎么结合
 *  分布式系统的认证方案
 *  基于Spring CloudSecurity 实现分布式认证授权

[Link 1]: https://www.jiagoujishu.com
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221120/6f6e8bc00227414092ec3dc30454301f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221120/782380a24255493d996b38e638d98119.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221120/ee827cca690c4c9cac29906291aab17b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221120/dc3160a8a17e4f128819a9264dad9dd7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221120/096d95654def4bef9ede6e08f69e419d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 5]: https://img-blog.csdnimg.cn/20201123140455199.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 6]: https://img-blog.csdnimg.cn/20201123140505497.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw_size_16_color_FFFFFF_t_70_pic_center 7]: https://img-blog.csdnimg.cn/20201123140523473.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2x1cWlhbmc4MTE5MTI5Mw==,size_16,color_FFFFFF,t_70#pic_center