【用户认证】密码加密，用户状态保存，cookie,session,token

小灰灰 2024-03-16 16:44 9阅读 0赞

## 相关概念 ##

### 认证与授权 ###

认证（authentication ）是验证你的身份的过程，而授权（authorization）是验证你有权访问的过程

### 用户认证的逻辑 ###

1.  获取用户提交的用户名和密码
2.  根据用户名，查询数据库，获得完整的用户信息，包括真正的密码
3.  比较提交的密码和查询到的密码
4.  如果二者相等，则用户认证成功；否则用户认证失败

## 密码加密 ##

### 加密与解密 ###

加密

**数据加密** 的基本过程，就是对原来为 **明文** 的文件或数据按 **某种算法** 进行处理，使其成为 **不可读** 的一段代码，通常称为 **“密文”**。通过这样的途径，来达到 **保护数据** 不被 **非法人窃取**、阅读的目的。

解密

**加密** 的 **逆过程** 为 **解密**，即将该 **编码信息** 转化为其 **原来数据** 的过程。

### 加密算法 ###

加密算法分 **对称加密** 和 **非对称加密**，其中对称加密算法的加密与解密 **密钥相同**，非对称加密算法的加密密钥与解密 **密钥不同**，此外，还有一类 **不需要密钥** 的 **散列算法**。

> 常见的 **对称加密** 算法主要有 `DES`、`3DES`、`AES` 等  
> 常见的 **非对称算法** 主要有 `RSA`、`DSA` 等  
> **散列算法** 主要有 `SHA-1`、`MD5` 等。

#### 对称加密 ####

**对称加密算法** 是应用较早的加密算法，又称为 **共享密钥加密算法**。在 **对称加密算法** 中，使用的密钥只有一个，**发送** 和 **接收** 双方都使用这个密钥对数据进行 **加密** 和 **解密**。这就要求加密和解密方事先都必须知道加密的密钥。

常见算法：

![image.png][]

1.  数据加密过程：在对称加密算法中，**数据发送方** 将 **明文** (原始数据) 和 **加密密钥** 一起经过特殊 **加密处理**，生成复杂的 **加密密文** 进行发送。
2.  数据解密过程：**数据接收方** 收到密文后，若想读取原数据，则需要使用 **加密使用的密钥** 及相同算法的 **逆算法** 对加密的密文进行解密，才能使其恢复成 **可读明文**。

#### 非对称加密 ####

**非对称加密算法**，又称为 **公开密钥加密算法**。它需要两个密钥，一个称为 **公开密钥** (`public key`)，即 **公钥**，另一个称为 **私有密钥** (`private key`)，即 **私钥**。

常见算法：RSA

因为 **加密** 和 **解密** 使用的是两个不同的密钥，所以这种算法称为 **非对称加密算法**。  
![image.png][image.png 1]

1.  如果使用 **公钥** 对数据 **进行加密**，只有用对应的 **私钥** 才能 **进行解密**。
2.  如果使用 **私钥** 对数据 **进行加密**，只有用对应的 **公钥** 才能 **进行解密**。

> **例子**：甲方生成 **一对密钥** 并将其中的一把作为 **公钥** 向其它人公开，得到该公钥的 **乙方** 使用该密钥对机密信息 **进行加密** 后再发送给甲方，甲方再使用自己保存的另一把 **专用密钥** (**私钥**)，对 **加密** 后的信息 **进行解密**。

比较：  
（1） 对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。

（2） 非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

（3） 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

#### 散列算法 ####

一类 **不需要密钥** 的 **散列算法**。

常见算法：md5,

### 加盐 ###

密码一般不会直接明文存储  
会通过使用一定的算法，例如md5，进行加密存储  
但是存在暴力破解的可能  
解决方法：最终密码=其他+盐值+md5（明文密码+盐值）  
大大提高了安全性  
盐值：随机的一段字符串

*  [密码加密——加盐算法（两种方式）\_fiance111的博客-CSDN博客][fiance111_-CSDN]

## 协议 ##

### OAuth3 ###

*  [准备工作 | 微信开放文档 (qq.com)][_ _ _qq.com]  
    ![image.png][image.png 2]

![image.png][image.png 3]

## 用户登录状态的保存 ##

HTTP 是一种不保存状态，即无状态（stateless）协议。

### cookie ###

*  将状态保存在客户端  
    ![Pasted image 20220612224250.png][]

1.  客户端访问服务端的登录接口
2.  服务端根据请求的用户名和密码，认证用户，认证成功后，向响应中写入Cookie

//创建cookie  
    Cookie cookie = new Cookie("islegal","yes");  
    //设置cookie的访问路径(哪些请求路径可以访问cookie)，默认所有都可以访问  
    cookie.setPath("/project1/checkServlet");  
    //设置生命周期，取值有三种:
     //大于0，单位是秒；
     //等于0，浏览器关闭
     //小于0，-1 （默认）内存释放  
    cookie.setMaxAge(60*60);  
    resp.addCookie(cookie);

![Pasted image 20220613142653.png][]  
3. 客户端接收响应，并保存  
![image.png][image.png 4]

1.  用户再次请求的时候，就会携带cookie  
    ![image.png][image.png 5]
2.  服务端如果可以访问cookie,则可以从中取出数据

Cookie[] cookies = req.getCookies();  
    if(cookies!=null){
          
        for (Cookie cookie : cookies) {
          
            System.out.println(cookie.getName()+" "+cookie.getValue());  
        }  
    }

> tip:  
> 如何修改cookie?  
> 新创建cookie,只要路径和cookie的名称一致，就可以修改cookie值

#### 优缺点 ####

![Pasted image 20220613140452.png][]

### session ###

基于服务端的状态保存

*  服务器会为每一次会话分配一个 Session对象
 *  同一个浏览器发起的多次请求,同属于一次会话( Session)

流程：

1.  首次使用到 Session时,服务器会自动创建 Session和JSeeisonID,并创建 Cookie用来存储 JSessionId发送回客户端,  
    ![Pasted image 20220613142745.png][]
2.  下一次统一浏览器再次访问服务器的时候，就会通过cookie携带JSessionId,来获取原来的Session

*  作用域
    
     *  一次会话(可能有多次请求，浏览器关闭，会话结束)有效
     *  不同组件之间的session可以共享,java中有一块专门的内存保存session

> 钝化：指关闭服务器后，未关闭浏览器，存储在session中的数据会通过序列化存储在磁盘上  
> 活化：指session中的数据被钝化过的浏览器未关闭，服务器重新启动并将存储在磁盘上的数据读取到session中

*  session生命周期  
    ![Pasted image 20220613144830.png][]

//通过req获得session ，
    //有一个boolean参数，默认true，没有则会创建一个新的会话;false如果没有回话，则不会创建
    HttpSession session = request.getSession();  
    System.out.println(session.getId());  
    //保存数据  
    session.setAttribute("name","gao");  
    //获取数据  
    String  name = (String)session.getAttribute("name");  
    //移除数据  
    session.removeAttribute("name");  
    //设置sesison的最大有效时间，单位秒  
    session.setMaxInactiveInterval(60*60);  
    //手动销毁  
    session.invalidate();

#### 分布式 ####

##### cookie #####

之前的方案都是在服务器端进行改造的，cookie方案是客户端的方案，就是把session信息保存到cookie中，即用户信息保存到cookie中，这样就不需要服务器保存session（用户信息）了。每次请求时，把此cookie传给服务器端，这样服务器端就知道是哪个用户了。

此方案比较实现比较简单，而且还**不占用服务器端的内存资源**。但是此方案的问题很大哦。

> 1、cookie在客户端是有限的，存储容量也是很小的  
> 2、安全是很有问题的，因为保存在本地，很容易被人拿到

##### session复制 #####

session复制是小型企业应用使用较多的一种服务器集群session管理机制，在真正的开发使用的并不是很多，通过对web服务器(例如Tomcat)进行搭建集群。

**存在的问题：**

session同步的原理是在同一个局域网里面通过发送广播来异步同步session的，一旦服务器多了，并发上来了，session需要同步的数据量就大了，需要将其他服务器上的session全部同步到本服务器上，会带来一定的网路开销，在用户量特别大的时候，会出现内存不足的情况

优点：

服务器之间的session信息都是同步的，任何一台服务器宕机的时候不会影响另外服务器中session的状态，配置相对简单

Tomcat内部已经支持分布式架构开发管理机制，可以对tomcat修改配置来支持session复制，在集群中的几台服务器之间同步session对象，使每台服务器上都保存了所有用户的session信息，这样任何一台本机宕机都不会导致session数据的丢失，而服务器使用session时，也只需要在本机获取即可

##### session绑定（黏贴） #####

我们利用nginx的反向代理和负载均衡，之前是客户端会被分配到其中一台服务器进行处理，具体分配到哪台服务器进行处理还得看服务器的负载均衡算法(轮询、随机、ip-hash、权重等)，但是我们可以基于nginx的ip-hash策略，可以对客户端和服务器进行绑定，同一个客户端就只能访问该服务器，无论客户端发送多少次请求都被同一个服务器处理

**缺点**：

*  容易造成单点故障，如果有一台服务器宕机，那么该台服务器上的session信息将会丢失
 *  前端不能有负载均衡，如果有，session绑定将会出问题

**优点**：

*  配置简单

##### redis:session集中管理 #####

![image.png][image.png 6]

#### 优缺点 ####

**session优点：**  
1.session中的信息存储在服务端，相比于cookie就在一定程度上加大了数据的安全性。  
2.session数据存储在服务端，相比于jwt方便进行管理，也就是说当用户登录和主动注销，只需要添加删除对应的session就可以，这样管理起来很方便。

session缺点：  
1.session存储在服务端，这就增大了服务器的开销，当用户多的情况下，服务器性能会大大降低。  
3、因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。  
4、用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，这样在分布式的应用上，相应的限制了负载均衡器的能力。这也意味着限制了应用的扩展能力。

### token ###

![image.png][image.png 7]

1.  客户端请求服务端登录
2.  服务端验证用户之后，返回响应的时候，生成一个token
    
    1.  常见生成token的方式就是JWT
3.  客户端接收响应，并保存token到localStor age或sessionStorage
4.  客户端下一次访问服务端的时候，就通过Header携带token

#### JWT ####

JSON Web Tokens

JWT 标准的 Token 有三个部分：

1.header(头部)，头部信息主要包括（参数的类型–JWT,签名的算法–HS256）  
2.poyload(负荷)，负荷基本就是自己想要存放的信息(因为信息会暴露，不应该在载荷里面加入任何敏感的数据)  
3.sign(签名)，签名的作用就是为了防止恶意篡改数据

中间用点分隔开，并且都会使用 Base64 编码，所以真正的 Token 看起来像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

##### Header #####

Header 部分主要是两部分内容，一个是 Token 的类型，另一个是使用的算法，比如下面类型就是 JWT，使用的算法是 HS256。

{
        
        "typ" : "JWT",
        "alg" : "HS256"
    }

上面的内容要用 Base64 的形式编码一下，所以就变成这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

##### Payload #####

Payload 里面是 Token 的具体内容，这些内容里面有一些是标准字段，你也可以添加其它需要的内容。下面是标准字段：

iss：Issuer，发行者
    sub：Subject，主题
    aud：Audience，观众
    exp：Expiration time，过期时间
    nbf：Not before
    iat：Issued at，发行时间
    jti：JWT ID

比如下面这个 Payload，用到了 iss 发行人，exp 过期时间，另外还有两个自定义的字段，一个是 name ，还有一个是 admin 。

{
        
        "iss" : "csdn.net",
        "exp" : "201511205211314",
        "name" : "维C果糖",
        "admin" : true
    }

使用 Base64 编码以后就变成了这个样子：

eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ

##### Signature #####

JWT 的最后一部分是 Signature ，这部分内容有三个部分，先是用 Base64 编码的 header 和 payload ，再用加密算法加密一下，加密的时候要放进去一个 Secret ，这个相当于是一个密钥，这个密钥秘密地存储在服务端。

header
    payload
    secret
    var encodedString = base64UrlEncode(header) + "." + base64UrlEncode(payload); 
    HMACSHA256(encodedString, 'secret');

处理完成以后看起来像这样：

SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

最后这个在服务端生成并且要发送给客户端的 Token 看起来像这样：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJuaW5naGFvLm5ldCIsImV4cCI6IjE0Mzg5NTU0NDUiLCJuYW1lIjoid2FuZ2hhbyIsImFkbWluIjp0cnVlfQ.SwyHTEx_RQppr97g4J5lKXtabJecpejuef8AqKYMAJc

客户端收到这个 Token 以后把它存储下来，下回向服务端发送请求的时候就带着这个 Token 。服务端收到这个 Token ，然后进行验证，通过以后就会返回给客户端想要的资源。

服务端如何验证？  
和生成signature的方式一样，然后比较signature是否一样

#### 优缺点 ####

*  不需要在服务端保存会话信息，特别适用于分布式微服务。
 *  自包含(Self-contained):负载中包含了所有用户所需要的信息，避免了多次查询数据库
 *  简洁(Compact):可以通过URL， POST参数或者在HTTP header发送，因为数据量小，传输速度也很快
 *  因为Token是以JSON加密的形式保存在客户端的，所以JWT是跨语言的，原则上任何web形式都支持。

## 安全问题 ##

### CSRF ###

*   *  [35.CSRF\_哔哩哔哩\_bilibili][35.CSRF_bilibili]
 *

当网站使用cookie保存用户登陆状态时，可能受到恶意站点的诱导，在不知道的情况下下向目标网站发起敏感请求  
csrf保护就是当向目标网站发起敏感请求时，要求携带csrf\_token,这是一个客户端浏览器附带的伪随机数，通过恶意站点发送的请求不会携带这个数据  
springsecurity默认开启csrf保护，对于put,post等方法（不包含get),要求请求时携带csrf\_token,前后分离项目本来就是使用token,不必开启csrf的保护

## 框架 ##

### Spring Security ###

*  [Spring Security][]
 *  [Spring Security Community :: Spring Security][Spring Security Community _ Spring Security]
 *

### Shrio ###

## 参考资料 ##

*  [认证 vs 授权 | Authing 文档][vs _ _ Authing]
 *  [Token的详细说明，看这一篇就够了 - 简书 (jianshu.com)][Token_ - _ _jianshu.com]
 *  [JSON Web Token 入门教程 - 阮一峰的网络日志 (ruanyifeng.com)][JSON Web Token _ - _ _ruanyifeng.com]
 *  [4种分布式session解决方案\_断橋殘雪的博客-CSDN博客][4_session_-CSDN]
 *  [session-cookie，jwt状态保持的差异，以及优缺点\_他们叫我浪浪的博客-CSDN博客][session-cookie_jwt_-CSDN]
 *  [浅谈常见的七种加密算法及实现 - 知乎 (zhihu.com)][- _ _zhihu.com]
 *  [对称加密和非对称的加密 的优缺点和理解 - 知乎 (zhihu.com)][_ - _ _zhihu.com]
 *  [密码加密——加盐算法（两种方式）\_fiance111的博客-CSDN博客][fiance111_-CSDN]

[image.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/62db1c334ece431cb5a07a10c03241e6.png
[image.png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/9e1731c312c041eb9f9f00aa314e9240.png
[fiance111_-CSDN]: https://blog.csdn.net/m0_60354608/article/details/130112235
[_ _ _qq.com]: https://developers.weixin.qq.com/doc/oplatform/Website_App/WeChat_Login/Wechat_Login.html
[image.png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/ebba636a2d8c483eae5399874a1740ed.png
[image.png 3]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/a5f2afc6c14b486b989e9308d26e242b.png
[Pasted image 20220612224250.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/c45660fd283c4fce9374a104ef8df5a5.png
[Pasted image 20220613142653.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/5f8a5acf40744bf3a32d359a2abce5ee.png
[image.png 4]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/f802609187444099b41debadcfafbd64.png
[image.png 5]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/08ce1e892d29475498af2ee16ce89dac.png
[Pasted image 20220613140452.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/5db8de2b9e8c4934ade631c713f25b3d.png
[Pasted image 20220613142745.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/1ccd88627acf4d33bb0c4a4b14204802.png
[Pasted image 20220613144830.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/36b9c51984214b218f85a63903457974.png
[image.png 6]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/2733bb2ba7654e33a3ea463f320dfa89.png
[image.png 7]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/fa76440a494b48dabba3c0075640c8e8.png
[35.CSRF_bilibili]: https://www.bilibili.com/video/BV1mm4y1X7Hc?p=36&vd_source=1fe29350b37642fa583f709b9ae44b35
[Spring Security]: https://spring.io/projects/spring-security
[Spring Security Community _ Spring Security]: https://docs.spring.io/spring-security/reference/community.html#community-help
[vs _ _ Authing]: https://docs.authing.cn/v2/concepts/authentication-vs-authorization.html
[Token_ - _ _jianshu.com]: https://www.jianshu.com/p/1422374a404b
[JSON Web Token _ - _ _ruanyifeng.com]: https://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
[4_session_-CSDN]: https://blog.csdn.net/qq_35620501/article/details/95047642
[session-cookie_jwt_-CSDN]: https://blog.csdn.net/weixin_43613053/article/details/84642140
[- _ _zhihu.com]: https://zhuanlan.zhihu.com/p/347114235
[_ - _ _zhihu.com]: https://zhuanlan.zhihu.com/p/42516761