知识点系列~SpringSecurity-认证授权

1·首先理解认证授权概念

1.1.1 认证

在互联网中，我们每天都会使用到各种各样的APP和网站，在使用过程中通常还会遇到需要注册登录的情况，输入你的用户名和密码才能正常使用，也就是说成为这个应用的合法身份才可以访问应用的资源，这个过程就是认证。认证是为了保护系统的隐私数据与资源，用户的身份合法方可访问该系统的资源。

当然认证的方式有很多，常见的账号密码登录，手机验证码登录，指纹登录，刷脸登录等等。

简单说: 认证就是让系统知道我们是谁。

1.1.2 授权

认证是为了保护身份的合法性，授权则是为了更细粒度的对数据进行划分，授权是在认证通过的前提下发生的。控制不同的用户能够访问不同的资源。

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

例如视频网站的VIP用户，可以查看到普通用户看不到的资源信息。

2·RBAC权限模型

~ RBAC模型（Role-Based Access Control -> 基于角色的访问控制）

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

if(主体.hasRole("总经理角色标识")){
    //查询工资 
}else{
    //权限不足
}

如果后期需要扩展业务，就要对该方法进行重写，导致维护成本变大，不可取 

~RBAC基于资源的访问控制(Resource-Based Access Control)是按资源(或权限)进行授权。

if(Subject.hasPermission("查询员工工资的权限标识")){
	// 查询员工工资
}

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

 3·常见认证方式

认证(登录)几乎是任何一个系统的标配，web 系统、APP、PC客户端等都需要注册、登录、授权。

1. Cookie-Session

早期互联网以 web 为主，客户端是浏览器，所以 Cookie-Session 方式最那时候最常用的方式，直到现在，一些 web 网站依然用这种方式做认证。

认证过程大致如下：

A. 用户输入用户名、密码或者用短信验证码方式登录系统；

B. 服务端验证后，创建一个 Session 记录用户登录信息 ，并且将 SessionID 存到 cookie，响应回浏览器；

C. 下次客户端再发起请求，自动带上 cookie 信息，服务端通过 cookie 获取 Session 信息进行校验；

弊端

• 只能在 web 场景下使用，如果是 APP 中，不能使用 cookie 的情况下就不能用了；

• 即使能在 web 场景下使用，也要考虑跨域问题，因为 cookie 不能跨域；（域名或者ip一致，端口号一致，协议要一致）

• cookie 存在 CSRF（跨站请求伪造）的风险；

• 如果是分布式服务，需要考虑 Session 同步（同步）问题；

2·jwt令牌无状态认证

JSON Web Token（JWT-字符串）是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。

认证过程:

A. 依然是用户登录系统；

B. 服务端验证，并通过指定的算法生成令牌返回给客户端;

C. 客户端拿到返回的 Token，存储到 local storage/Cookie中；(f12,点击Application即可看到)

D. 下次客户端再次发起请求，将 Token 附加到 header 中；

E. 服务端获取 header 中的 Token ，通过相同的算法对 Token 进行验证，如果验证结果相同，则说明这个请求是正常的，没有被篡改。这个过程可以完全不涉及到查询 Redis 或其他存储；

优点

A. 使用 json 作为数据传输，有广泛的通用型，并且体积小，便于传输；

B. 不需要在服务器端保存相关信息，节省内存资源的开销；

C. jwt 载荷部分可以存储业务相关的信息（非敏感的），例如用户信息、角色等；