00：HTTP无状态（为了保持状态，前端好麻烦，又要自己存，又要想办法带出去，于是使用cookie）
01：Cookie 将用户信息，在每次请求时候 带给后端（但是自己存储大小有限，同时不太安全，但是是基石）
02：Session 用户登录，后生成一个SessionId（该Id用来映射在服务端用户的信息使用）,然后返回给前端，前端请求的时候在将SessionId带给后端，后端根据它再去验证（需要每次查询数据库）（通过cookie将sessionId带过去）
03：JWT （通过cookie将sessionId带过去）
JWT 生成和验证的过程
1. 用户登录并生成JWT
用户登录 : 用户通过前端提交登录请求(通常包含用户名和密码)到服务器.
验证用户信息: 服务器验证用户名和密码是否正确.
生成JWT:
服务器生成JWT的三个部分: Header、Payload、Signature.
Header: 指定JWT的类型和签名算法.例如:
{
"alg": "HS256",
"typ": "JWT"
}
Payload: 包含用户信息和其他声明.例如:
{
"userId": "123456",
"username": "user1",
"role": "admin",
"iat": 1623847200, // 签发时间
"exp": 1623850800 // 过期时间
}
Signature: 使用Header和Payload, 加上服务器的密钥, 按照指定的签名算法生成签名.例如, 使用HMAC SHA-256算法生成签名
返回JWT给前端: 服务器将JWT(Header + Payload + Signature)返回给前端.
2. 前端携带JWT进行请求
前端存储JWT: 前端将接收到的JWT存储在localStorage、sessionStorage或Cookie中.
请求时携带JWT: 前端在后续请求的HTTP头部中携带JWT:
3. 服务器验证JWT
提取并解析JWT: 服务器从请求头中提取JWT, 并将其分成Header、Payload和Signature三部分.
重新生成签名: 服务器使用Header和Payload, 再次生成签名:
验证签名: 服务器比较重新生成的签名和JWT中的原始签名:
检查有效期: 服务器检查Payload中的过期时间(exp)是否过期:
完成验证: 如果签名验证通过且JWT未过期, 说明JWT是有效的, 服务器可以信任JWT中的用户信息.
