SpringCloudSecurityOAuth2.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（如不⽀持co
okie就需要特殊处理）
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 实现分布式认证授权
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议