- 主题:服务端每次都要解析和验证 jwt 是否通过吗?
这儿redis做内存缓存
sign做key，解码后的明文做value
ttl和jwt自身ttl看齐
【 在 feed (鳄鱼) 的大作中提到: 】
: jwt 还需要用 redis 吗? jwt 自己就带了失效时间呀
: 我的理解是之前很短的那种 token,才需要存放在 redis 里,服务器自己去查来验证.
: jwt 就不用这样麻烦了, 但取而代之的是 解析起来,应该也挺消耗效率的, 不知道有没有偷懒的方法
: ...................
--
FROM 114.92.202.*
正文只签名不加密还好
正文如果要解密就折腾了，JWT那个破算法用RSA直接加密的
【 在 majianglin (逍遥一狂) 的大作中提到: 】
: 楼上说的对
: Redis也是需要网络连接的，一些响应式框架这个都是IO异步操作的，本地字符串加密解密还是足够快的
--
修改:oldwatch FROM 114.92.202.*
FROM 114.92.202.*
两回事
cookies中的redis是集中存储
这儿的redis仅仅是个cache用来回避rsa解码的开销（如果你很关注）
redis可以用任何一种本地/分布缓存方案替代
【 在 feed (鳄鱼) 的大作中提到: 】
: 好不容易搞明白,又被你搞晕了
: 用 jwt 不是更适合分布式系统吗?不是比 redis 存 token 更好吗?
: 如今的主流架构都是怎么做的呢?
: ...................
--
FROM 114.92.201.*
jwt的主要优势是可以直接携带业务级权限控制信息
不用像传统OAuth方案一样还要通过用户索引再发起一次到（单一入口）的权限明细查询
当然，和任何离线校验方案一样，远程吊销都是没法简单处理的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你们都已经在用了。说服你们费时费力能赚几个钱。我去捡个瓶子就回来了。
: 反正以我的审美，让数据状态穿透可控制的边缘，并且依赖于不那么可靠的安全体系的这种方案，听起来就很蠢。
: 我猜这种方案在 java 社区流行，应该是因为以前的 java http client 缺少管理 session cookie 的能力。
: ...................
--
FROM 114.92.201.*