一、Session
二、JWT
三、比较
基于JWT（JSON Web Token）和Session身份验证之间的争论是现代 Web 开发中的一个要点。
- JWT 身份验证：无状态。服务器生成一个令牌，客户端存储该令牌并随每个请求一起提供，服务端仅需按照JWT规则校验即可完成验证。
- Session身份验证：有状态。服务器为用户创建会话，并将会话数据存储在服务器端，客户端仅保存会话标识符SessionId或Token，每次请求上传至后端进行验证和获取会话基本信息。
| 维度 | JWT | Redis |
|---|---|---|
| 扩展性 | - 无需在服务器端存储会话信息，易于扩展 - 可以与其他身份验证机制（如 OAuth）结合使用 | - 可以存储大量的会话信息，适用于大规模应用 - 可以与其他功能（如缓存、消息队列）结合使用，提供更多扩展性 |
| 性能 | - 无需查询数据库或访问外部存储，验证速度较快 - 适用于简单的身份验证场景 | - 需要与 Redis 服务器进行通信，可能会有网络延迟 - 适用于复杂的会话管理和存储需求 |
| 灵活性 | - 无需依赖外部存储，适用于分布式环境 - 可以自定义 payload 保存额外的用户信息 | - 提供丰富的数据结构和操作命令，适用于各种场景 - 可以使用 Redis 提供的其他功能（如发布/订阅、事务） |
| 复杂性 | - 需要在客户端和服务器端实现 JWT 的生成和验证逻辑 - 需要处理 JWT 的过期和刷新机制 | - 需要在服务器端实现与 Redis 的交互逻辑 - 需要处理 Redis 的连接和错误处理 |
| 持久性 | - JWT 的有效期由过期时间决定，可以短暂或长期有效 - 可通过刷新令牌保持客户端状态 | - Redis 提供持久化选项，可以将会话信息保存到磁盘上 |
| 安全性 | - 使用签名保证数据的完整性和真实性 - 无状态，不需要在服务器端存储会话信息 | - 通过设置过期时间和权限验证提高安全性 - 可以使用 SSL/TLS 加密传输数据 - 需要在服务器端存储会话信息，需要确保 Redis 的安全性 |
| 缺点 | - 会话存在违规行为或Jwt密钥泄露，Redis可以立即从存储中删除会话，而JWT 列入黑名单则很棘手，在最坏的情况下，您只能等待令牌过期 - 如果您Jwt无状态令牌的荷载中记录了大量信息，存储和通讯将变得很重 | - 会话在服务端存储在Redis中，会话验证一定程度带来更多开销 - 当更多用户进行身份验证时，为提升体验，需要更多分片来提升性能，意味着更多成本 |
| 优点 | - 可扩展性，由于其无状态特性，JWT 非常适合分布式系统 - 灵活性，它们可以跨不同的领域和应用程序使用 - 安全性，如果实施得当，它们可以提供一种安全的方式来处理用户身份验证 | - 可靠性，服务器的会话记录充当集中的事实源，使管理用户会话变得简单 - 撤销效率，通过删除或使会话记录失效，可以快速撤销访问，确保最新的会话有效性 - 会话中可以存储更多且安全的信息 |
建议：
- 在可信环境中，实体之间使用 JWT，例如授权服务之间的请求、......。
- 在不可信源之间进行通信时，请使用基于会话的身份验证。
参考资料
https://dev.to/codeparrot/jwt-vs-session-authentication-1mol