前序
最近，我想做一个基于Spring Cloud的认证许可平台，总的想法是可以许可给服务器，所以我想做一个基于代理的无入侵方法。
发现新版本的Spring Cloud Security，OAutp.0似乎做了一些改变，说互联网随便翻动，但没有针对Spring Security OAutp.0的认证认可体系文章。
后来，我想结合一些资料和自己的整理，建立了认证认可系列，成为一个整体。
其实之前也做了一些关于认证许可证的报道，但是总觉得有些零碎、不成体系，没有做过Security、OAutp.0、JWT的人一副陌生的表情。
这次我打算把这方面的知识重新从头开始整理，逐步推进。 尽量不要长篇大论，广泛地打动观众的头脑，谋求一个个的推进。
不用说，要一口吃下饭，基础的东西其实也很重要，所以从头开始说吧。
基础概念
1、认证概念
在这个移动时代，嘀嘀打车、淘宝、微信等，我们每天都在切换各种APP。 例如，以嘀嗒为例说明认证的基础概念。
比如说，我们在使用嘀嗒之前需要注册吧。 然后，输入用户名和密码(或认证码)登录帐户。
在这里登陆的过程
认证
那你为什么要认证？
身份验证实际上是为了保护系统资源，只有在用户id合法的情况下才能访问资源。
认证
用户身份验证是确定用户身份是否合法的过程，用户访问系统资源时必须验证用户的身份
信息、身份可以合法继续访问，不符合规则拒绝访问。
典型的用户认证方法如下。
使用用户名和密码登录
二维码登录
手机短信登录
指纹识别
脸部识别
2、对话概念
想想看。 如果我每次用微信点击按钮都要求认证，我会不会疯了？ 因此，为了避免这种问题，用户认证结束后，可将用户信息保存在会话中。
会话是为系统保持当前用户登录状态而提供的机制。
一般对话方法：
基于会话的
基于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、许可证概念
以微信为例，用户登录成功后，可以使用发朋友圈、添加好友、发红包等功能。
但是，这个时候，我们必须绑好卡片，才能使用发红包的功能。 也就是说，你无权发红包。
只有绑定银行卡的用户才能发红包。 也就是说，此时的用户有发送红包的权限。
根据此用户的权限控制用户资源使用的过程是批准的。
*为什么要授权？ **
认证是为了验证用户的合法性，许可是为了以更小的粒度分割数据，许可发生在认证完成后，用于控制不同的用户访问不同的资源。
许可
:授权是用户身份验证根据用户权限控制用户对资源的访问的过程，如果有权访问资源，则照常访问，否则照常访问
权限拒绝访问。
认可的数据模型
我知道写代码有设计模式，总结起来，授权也有那个数据模型
也就是说，哪些用户、哪些权限以及可以访问哪些资源，如下图所示。
关于上图，可以抽象出几个关键点：
世卫组织对世卫组织进行how操作
世卫组织：用户
wat :资源
how :权限
例如，用户02可以对商品信息01进行修正操作，但实际上这也是典型的许可方案。 详细情况将在后面叙述
然后，在上图中，将其关系抽象出来，落地到数据库表的设计中，成为经典的
许可方案
如何实现许可证的设计？ 其实业界有几个一般的方案：
ACL访问控制列表的表现力和执行力较弱
RBAC是基于角色的权限控制，缺乏表现力，只能表现正向的访问控制，难以进行反向的控制
ABAC是基于属性的权限控制，可以很好地表现反向访问控制，但是执行能力很低
PBAC基于策略的权限控制将RBAC和ABAC的最佳特性相结合，为更多APP应用场景提供复杂灵活的管理控制需求
其中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问题，实际上是用户通过角色进行权限关联。
一个用户可以有多个角色，一个角色可以有多个权限。 这将配置用户-角色-权限授权模型。 在模型中，如图所示，用户和角色之间、角色和权限之间一般是多对多关系。
这里有核心点。 是角色。 可以理解为权限的集合体。 是一种载体。 例如论坛版主和超级管理员等，版主可以管理和管理帖子的权限。 要将这些权限授予某个用户，只需向该用户授予角色即可，而无需直接与权限绑定。
然后，添加权限组的设计
在实际的APP演示中可以看出，在用户数量非常多的时候，给每个用户发放许可证，真的很累，手很抽筋。 因此，在这种情况下必须对用户进行分组。 分组后，也可以直接授权用户组。 此时用户拥有的权限是用户个人权限和用户组权限之和。
看看进化的模型：
然后，添加页面功能的权限设计
在我们实现的场景中，对功能模块的操作、菜单访问、按钮访问、文件上传等都属于权限范畴。
有些权限设计通过将功能操作作为一个类，将文件、菜单、页面元素等作为另一个类来配置“用户-角色-权限-资源”的许可模型。
对数据表建模时，可以统一管理功能操作和资源，也可以直接与权限表相关联，从而提高便利性和可扩展性
例如，这里有菜单、文件等功能。 让我们看看权限表更新后的设计。
这里有几个核心点：
权限表中的权限类型字段允许您自由扩展自己的权限。 例如
孟奴
菜单权限、
文件
表示文件权限。 扩展时制作权限XXX关联表就可以了。
这里权限表、菜单表、权限菜单关联表是一对一的关系，所以在添加一个菜单的同时，需要在三个表中插入记录。 也可以在设计时省略关联表，直接调用权限表和菜单表进行关联。 但是，必须在权限表中添加记录菜单ID的字段，以便以后更容易区分。
到目前为止，基于RBAC的权限模型的设计已经完成，完成了完整的设计图
最后的顺序
本章对基础概念做了一些铺垫，RBAC是重点内容，也是目前设计权限下的常用模型。
关于RBAC的钟表设计，实际上，以明确who、what、how为主。 具体如何实现取决于你的业务需求。 没有完美的设计，只能继续重复。
后续计划大致如下
使用Spring Cloud Security
与OAutp.0的结合方法
分布式系统的认证方案
基于Spring CloudSecurity的分布式认证许可证实现
