| 指标 | session | token | jwt |
|---|---|---|---|
| 状态存储位置 | 内存（所谓的session） | redis | 无 |
| 状态表现形式 | uuid | uuid | 用户id、用户ip、过期时间。签名并加密 |
| 优点 | 易操作 | 易操作 | 不需要存储状态，容灾性强 |
| 缺点 | 不适合集群环境 | 依赖redis稳定性 | 实现较复杂，无法踢出登录，依赖签名/加密算法 |
jwt虽然依赖密码学，技术含量比较高。
但是无法踢出登录是硬伤，没有好的解决方案！
比如以下方案：
而如果想要用jwt，就必须满足没有踢出登录的应用场景，就算有也能保证踢出用户不会操作（比如toB软件）
另外，控制登录超时也不是很方便，不可能每次访问都得刷新jwt的过期时间吧。如果用refresh_token，就得统计分析access_token应该设置多长：
设置短了，刷jwt太频繁、设置长了，超时时间又不稳定。就很难控制。