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, toen 里包含信息 {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 ~ 黑名单数量
1
Select Language