JWT 的基本就不再过多阐述 思考的问题前提: 比如我们面对一个千万级用户的系统. * 客户端需要和服务端交互, 假设 50% 的接口需要校验 * 10% 的接口需要获取个人信息 如果是 token 那么代表着 50% 的流量都需要去查 db(任何 db 都可以)如果用 jwt 我可以减少到 10%, 甚至更少 至于常见的 JWT 诟病解决方案 两个小时没操作自动掉线分钟级别过期 access_token, 2h 过期 refresh_token, 完全可以做到 黑名单, 强制下线功能分钟即被过期 access_token, token 里包含信息 {uid: xxxx, token_version: xxx}修改密码, 或者强制下线, 修改 db 里的 token_version当要刷新 token 的时候, 校验客户端 token 里的 token_version 是否等于 db 里的 token_version, 不等于强制下线.(是在每一次去校验还是在刷新 token 的时候去校验都可以) 单台设备下线, 这个我认为是业务的逻辑分钟即被过期 access_token, token 里包含信息 {uid: xxxx, device_id: xxx}当要刷新 token 的时候, 校验客户端黑名单 db 里是否包含这个 device_id 为什么要用 JWT ? 使用 token 会有千万级用户请求 * (存 token + 查 token redis)... 用户名,xxx 存储, 下线, 黑名单为什么不直接存储 token ? token 可能千万级别, 但是黑名单保守估计不会超过 1w, 并且我可以把黑名单 token 有效期设置成 refres_token 的有效期(极大的减少了黑名单 token 的数量), 这样子当黑名单过期了, 那么 refresh_token 也不能再使用了(如果去颁发, 在黑名单中也颁发不了)如果一个用户可能登录 5 个设备, 那么存储的 token 量就是 1000w * 5, 而 jwt 就是 0 ~ 黑名单数量 token, 黑名单, jwt, 过期
还有 access_token 一个就够了, 为什么还要有 refresh_token, 除了官方说的安全之外, 就是可以作为两个时间点去使用. access_token 每次都要校验, 可以简单的校验, refresh_token 使用的频次比较少, 这时候可以做更完整的校验.
用了 JWT 还要存 token 到服务端，每次还要查版本号和黑名单，不是脱裤子放屁吗？ 用户权限之类的更新了怎么办？难道让用户退出重新登录一遍吗？ 查一次缓存就能解决的事情，不要太小看 Redis 的性能了。 而且 JWT 不是 100%安全的： https://github.com/yihleego/jwtcrack
你这个都依赖 **分钟级别过期 access_token** 你加个 token_version 那每次刷新 jwt 就要查询数据库，而且你刷新的非常频繁，这不又和原来一样 同样的还有检查 device_id 要查询数据库
