一、基于 Cookie-Session 的登录鉴权
1. 实现原理
用户登录成功后，服务端生成唯一的 Session ID，并将其存储在服务器内存或数据库中。通过 Set-Cookie 响应头将 Session ID 返回给浏览器，浏览器后续请求自动携带该 Cookie。服务端通过 Session ID 验证用户身份。
2. 优缺点
优点：
实现简单：易于理解和实现，兼容性强。兼容性好：适用于传统 Web 应用。
缺点：
服务器内存压力：Session 数据存储在服务器内存中，用户量较大时对内存有较高要求。分布式问题：在集群或分布式架构中，需要同步 Session 数据，影响性能。单点故障：如果服务器宕机，Session 数据可能丢失。
3. 补充
IP Hash 映射：通过请求的 IP 进行 Hash 映射，确保同一用户始终访问同一台服务器。但如果服务器宕机，会导致部分用户 Session 数据丢失。
二、基于 Token（如 JWT）的无状态认证
1. 实现原理
用户登录成功后，服务端生成一个签名后的 Token（如 JWT），返回给客户端。客户端将 Token 存储在 LocalStorage 或 Cookie 中，并在请求头中携带（如 Authorization: Bearer
2. JWT 结构
JWT 由三部分组成：
Header：描述 Token 类型和加密算法。
{
"alg": "HS256", // 加密算法
"typ": "JWT" // Token 类型
}
Payload：存放用户信息和声明。
{
"sub": "1234567890", // 用户ID
"name": "John Doe", // 用户名
"iat": 1516239022, // 签发时间
"exp": 1516242622 // 过期时间
}
Signature：对 Header 和 Payload 的签名，确保 Token 的完整性。
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret
3. 优缺点
优点：
无状态：服务端无需存储 Token，天然支持分布式系统。自包含：Token 中包含用户信息，减少数据库查询。安全性：通过签名防止篡改，支持加密算法（如 HMAC、RSA）。
缺点：
无法主动失效：Token 一旦签发，服务端无法主动使其失效（除非过期）。续期问题：Token 过期后，用户必须重新登录，难以实现无感刷新。
三、Redis 存储 Token 的增强方案
1. 实现原理
用户登录成功后，服务端生成一个随机 Token（如 UUID），并将其作为 Key，用户信息作为 Value 存储在 Redis 中，设置过期时间。客户端存储 Token，并在请求时携带。服务端通过 Redis 验证 Token 的有效性。
2. 优缺点
优点：
主动失效：通过删除 Redis 中的 Token，可以主动使其失效。会话控制：可以限制用户的并发会话数。
缺点：
依赖 Redis：增加了系统架构的复杂度。登录时间控制问题：固定过期时间可能导致用户体验不佳，滑动过期可能增加安全风险。
3. 适用场景
需要高安全性和会话控制的中大型应用。
四、OAuth 2.0 / 第三方登录
1. 实现原理
允许用户通过第三方平台（如微信、GitHub）登录。服务端通过 OAuth 协议获取用户授权信息，完成本地登录或注册。
2. 授权码模式流程
用户点击“第三方登录”，跳转到第三方授权页面。用户授权后，第三方回调应用并返回授权码（Authorization Code）。服务端用授权码向第三方换取 Access Token。服务端通过 Access Token 获取用户信息（如 OpenID），完成本地登录或注册。
3. 适用场景
需要第三方账号快速登录的应用。
五、双 Token 机制
1. 实现原理
Access Token
作用：用于访问受保护的资源，携带用户信息和权限。特点：
有效期较短（如 5 分钟）。每次请求都需要携带。过期后需要重新获取。
Refresh Token
作用：用于获取新的 Access Token。特点：
有效期较长（如 24 小时）。不携带用户信息，仅用于刷新 Access Token。
存储在安全的地方（如 HttpOnly Cookie）。
2. 工作流程
用户登录
用户提交账号密码，服务端验证成功后生成 Access Token 和 Refresh Token，并返回给客户端。
请求受保护资源
客户端在请求头中携带 Access Token（如 Authorization: Bearer
刷新 Access Token
客户端检测到 Access Token 过期后，使用 Refresh Token 请求新的 Token。服务端验证 Refresh Token：如果有效，生成新的 Access Token 和 Refresh Token，并返回给客户端。如果过期，返回错误码（如 401 Unauthorized），提示用户重新登录。
用户重新登录
如果 Refresh Token 也过期，客户端提示用户重新输入账号密码登录。
3. 优缺点
优点
○ Access Token 有效期短，减少泄露风险。即使 Access Token 被截取，攻击者也仅能在短时间内利用。
○ Refresh Token 存储在安全的地方（如 HttpOnly Cookie），避免被恶意脚本窃取。
○ 用户无需频繁登录，通过 Refresh Token 自动刷新 Access Token，提升了用户的使用便利性。
○ 可以根据业务需求调整 Access Token 和 Refresh Token 的过期时间，支持滑动过期和会话控制。
缺点
○ 相比单 Token 机制，双 Token 机制的实现更为复杂，需要额外处理 Refresh Token 的存储、验证和失效逻辑。
○ 无法主动失效：Token 一旦签发，服务端无法主动使其失效。
六、双 Token 三验证机制
1. 背景
单 Token ,双 Token,Redis 存储 Token 都没有真正完全解决这两个问题
有效期设置矛盾：短有效期影响用户体验，长有效期增加安全风险。无法主动失效：Token 一旦签发，服务端无法主动使其失效。
2. 实现原理
双 Token：
Access Token：有效期短（如 5 分钟），用于日常请求。Refresh Token：有效期长（如 24 小时），用于刷新 Access Token。
三验证：
Access Token 验证：每次请求验证 Access Token 是否有效。Refresh Token 验证：Access Token 过期后，使用 Refresh Token 刷新。Redis 验证：Refresh Token 存储于 Redis，确保只能使用一次。
3. 流程
用户登录：
生成 Access Token 和 Refresh Token。将 Refresh Token 存储到 Redis，设置过期时间。返回双 Token 给客户端。
请求验证：
客户端携带 Access Token 请求资源。服务端验证 Access Token：
有效：处理请求。过期：返回 401，提示客户端刷新 Token。
刷新 Token：
客户端使用 Refresh Token 请求新的 Token。服务端验证 Refresh Token：
有效：生成新的双 Token，更新 Redis。无效：返回 401，提示用户重新登录。
主动失效：
服务端检测到异常（如异地登录），删除 Redis 中的 Refresh Token，使其失效。
4. 优点
安全性：
Access Token 有效期短，减少泄露风险。Refresh Token 存储于 Redis，可主动失效。
用户体验：
用户无需频繁登录，通过 Refresh Token 自动刷新 Access Token。
灵活性：
支持滑动过期和会话控制。
5. 适用场景
对安全性和用户体验要求较高的系统（如金融、电商）。需要支持多设备登录和会话管理的场景。
七、总结
方案
状态管理
扩展性
安全性
适用场景
Cookie-Session
有状态
低
中
传统 Web 应用
JWT
无状态
高
中高
分布式系统、移动端
Redis + Token
有状态
高
高
需会话控制的企业应用
OAuth 2.0
依赖第三方
高
高
第三方登录集成
双 Token 机制
有状态
高
极高
高安全需求场景
双 Token 三验证
有状态
高
极高
高安全需求场景
通过 双 Token 三验证机制，系统在安全性、用户体验和灵活性之间取得了平衡，是登录鉴权模块的最佳实践方案。