|
|
jwt与token+redis，哪种方案更好用？
关注者
1,365
被浏览
1,008,482
108 个回答
如果项目并不大，jwt 是个好选择，天然的去中心化模式，会话状态由令牌本身自解释，简单粗暴。
但是缺点也很明显，如题所示，一旦下发便不受服务端控制，如果发生 Token 泄露，服务器也只能任其蹂躏，在其未过期期间不能有任何措施。
常见的做法是从 jwt 上再封装一层，提供一个类似黑名单的机制，每次访问系统时先检查此 jwt 令牌是否已经被拉黑。
此模式虽然暂时解决了问题，但是此时你会发现，项目架构又回到了传统 Session 模型中，对 jwt 来讲属于自断招牌。
这时候又凸显出了传统 Session 模型的好处，服务器生成令牌下发给前端，前端只持有令牌本身，而令牌代表的数据则完全由服务器说了算。
此种模式下：什么Session会话、踢人下线之类的都是信手拈来，但是缺点又回来了：失去了去中心化，水平扩展比较难，且服务器需要维护所有用户的数据状态，性能压力比较大。
常见解决方案也很简单，那就是把会话数据放到专业的数据中心，比如 Redis，此模式既保证了服务器对会话数据的可控性，又保证了服务水平扩展时的会话一致性。
对此模式践行比较完善的框架推荐你了解一下 Sa-Token，此框架扩展了 Token-Session 模型，将会话数据放在了 Redis 下，并提供了多种Session序列化方案，诸如注销登录、权限认证、踢人下线等常见功能全部一行代码就可以完成。
附个链接：
2种Token：
1. 去中心化的JWT token
1. 去中心化，便于分布式系统使用
2. 基本信息可以直接放在token中。 username，nickname，role
3. 功能权限较少的话，可以直接放在token中。用bit位表示用户所具有的功能权限
缺点：服务端不能主动让token失效