springsecurity oauth2.0 认证与授权基础知识1

一 认证

认证是为了保护系统的隐私数据与资源， 用户的身份合法方可访问该系统的资源 。

认证 ：用户认证就是判断一个用户的身份是否合法的过程，用户去访问系统资源时系统要求验证用户的身份信息，身份合法方可继续访问，不合法则拒绝访问。常见的用户身份认证方式有：用户名密码登录，二维码登录，手机短信登录，指纹认证等方式。

简而言之： 认证就是判断用户的身份的合法性，一般特指用户登录时身份的判断。

二 授权

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

简而言之： 用户通过认证后，控制不同的用户能够访问不同的资源的过程。

三   会话

会话就是系统 为了保持当前 用户的登录状态所提供的机制 ，常见的有基于session 方式、基于 token 方式等。

原因在于： 用户认证通过后，为 了避免用户的每次操作都进行认证可将用户的信息保证在会话中 。

3.1 基于session的会话方式

思路：

用户认证成功后，在服务端生成用户相关的数据保存在 session( 当前会话 ) 中，发给客户端的

sesssion_id 存放到 cookie 中，这样用户客户端请求时带上 session_id 就可以验证服务器端是否存在 session 数 据，以此完成用户的合法校验，当用户退出系统或session 过期销毁时 , 客户端的 session_id 也就无效了。

3.2 基于token的会话方式

思路：

用户认证成功后，服务端生成一个 token 发给客户端，客户端可以放到 cookie 或 localStorage

等存储中，每次请求时带上 token ，服务端收到 token 通过验证后即可确认用户身份。

 3.3 两种方式的区别联系

1.基于 session 的认证方式由 Servlet 规范定制， 服务端要存储session信息需要占用内存资源，客户端需要支持 cookie；

2. 基于 token 的方式则 一般不需要服务端存储token，客户端需要存储token，通过cookie或者并且不限制客户端的存储方式localstorage，

如今移动互联网时代 更多类型的客户端需要接入系统，系统多是采用前后端分离的架构进行实现，所以基于 token 的方式更适合。

3.4 授权模型

授权可简 单理解为Who对What(which)进行How操作

Who ，即主体（ Subject ），主体一般是指用户，也可以是程序，需要访问系统中的资源。

What ，即资源 （Resource ），如系统菜单、页面、按钮、代码方法、系统商品信息、系统订单信息等。

How ，权限 / 许可（ Permission ），规定了用户对资源的操作许可，权限离开资源没有意义，

如用户查询权限、用户添加权限、某个代码方法的调用权限、编号为 001 的用户的修改权限等，通过权限可知用户

对哪些资源都有哪些操作许可。

常见的数据模型：

四 基于RBAC授权模型

4.1 基于角色的授权

RBAC基于角色的访问控制(Role-Based Access Control)是按角色进行授权。例如：主体的角色为总经理可以查 询企业运营报表，查询员工工资信息等，访问控制流程如下：

 授权代码可表示如下：

if(主体.hasRole("总经理角色id")){ 
查询工资 
}

如果上图中查询工资所需要的角色变化为总经理和部门经理，此时就需要修改判断逻辑为 “ 判断用户的角色是否是 总经理或部门经理” ，修改代码如下：

if(主体.hasRole("总经理角色id") || 主体.hasRole("部门经理角色id")){ 
查询工资 
}

缺点：根据上边的例子发现，当需要修改角色的权限时就需要修改授权的相关代码，系统可扩展性差。

4.2 基于资源的授权

RBAC基于资源的访问控制（Resource-Based Access Control）是按资源（或权限）进行授权 ，比如：用户必须 具有查询工资权限才可以查询员工工资信息等，访问控制流程如下：

授权代码可以表示为：

if(主体.hasPermission("查询工资权限标识"))
{ 
查询工资
 }

优点： 系统设计时定义好查询工资的权限标识， 即使查询工资所需要的角色变化为总经理和部门经理也 不需要修改授权代码，系统可扩展性强 。

五 学习资料地址

1.代码地址

https://gitee.com/jurf-liu/spring-security-project.git

 2.视频地址

   01.认证授权课程介绍_哔哩哔哩_bilibili

3.资料地址