纯 JWT TOKEN
纯 JWT TOKEN 的优势就是简单，不需要引入额外的存储系统，JWT TOKEN 里本身就携带了用户信息（比如 User Id）和过期时间，后端只需要分发 Token 给前端，然后前端在每次请求后端时携带上 Token （一般放在响应头），后端只需要验证 Token 的合法性和有效性即可。
纯 JWT TOKEN 的劣势主要有以下几点：
- 无法主动注销：由于 JWT TOKEN 是无状态的，只有在前端向后端发出请求时，后端才能验证 Token 的有效性，所以无法实现服务端主动登出用户的功能，要么等到 TOKEN 过期前端再次请求，要么前端主动不携带 Token（这种方法并不安全，不代表 TOKEN 被注销了，TOKEN 仍然有效，只是前端不再使用它了）。
- 数据泄露风险：JWT TOKEN 是直接暴露在前端的，攻击者可以直接拿着这个 Token 冒充用户。如果服务端的签名密钥泄露，攻击者甚至可以伪造任意 Token（包括伪装成管理员），风险更大。
- 无法精准控制登录状态：用户权限变更（例如封号、禁用）或想“踢下线”一个用户时，只能等 Token 自己过期，或者强制换一批密钥导致所有人同时下线。
如果业务没有涉及到需要主动注销 Token 的场景，且对数据泄露风险不敏感，那么纯 JWT TOKEN 是一个不错的选择，简单高效。
Redis + JWT TOKEN （单点登录）
使用 Redis + JWT TOKEN 的方式，通常是在用户登录时，后端生成 JWT TOKEN 并存储在 Redis 中，同时将 Token 返回给前端。前端在每次请求时携带 Token，后端在验证 Token 的合法性和有效性时，还会去 Redis 中检查该 Token 是否存在。
用上 Redis 最主要的目的就是为了更好的管控 Token 的生命周期，可以让服务端在任何时候主动注销 Token。比如：用户登出时，后端可以直接从 Redis 中删除该 Token，这样即使前端还携带着该 Token，后端也会拒绝请求。
当然，使用 Redis + JWT TOKEN 也有一些劣势：
- 增加了状态和依赖：
纯 JWT 是完全无状态的，只依赖签名密钥即可验证。引入 Redis 之后，认证链路就变成了：客户端 → 网关 / 服务 → Redis，Redis 故障或网络抖动都会影响登录态校验，需要部署高可用集群。 - 性能开销变大：
每次请求都要多一次 Redis 访问（读 token 或 userId 对应的会话信息），增加了网络开销和延迟，尤其是在高并发场景下，可能成为性能瓶颈。 - 运维复杂度提升：
需要额外维护 Redis 集群，监控其健康状态，处理数据过期、清理等问题，增加了系统的复杂度。
打赏
微信
支付宝
评论
