带吊销的 jwt 与随机生成字符串的 token 相比，有什么优势？

[lookas2001]

rt。
之前看到 v2 上有一些帖子，但是这一点我没怎么弄明白。
如果 jwt 可以吊销，那数据库（关系型或者 kv 型）中就需要存储一个 token 列表。这样的话跟随机生成的 token 在存储上的成本就一样了。
jwt 因为要包含一系列信息，所以长度要比普通 token 长，那传输上相比于随机生成的 token 也没有优势了。
在处理上，jwt 还需要解码，解密，校验的过程，运算成本也比随机生成的 token 高。
如果这样看，jwt 岂不是没有优势。

[crab]

功能多。

[lookas2001]

@crab 比如？

[rannnn]

jwt client 解码就知道有没有过期

[lookas2001]

@rannnn 但是不知道有没有效，在 jwt 可以吊销的情况下，client 不与 server 做数据交换，client 是不能知道自己的 token 还能不能用的

[mingqing]

jwt 包含信息，且不可伪造，随机 token 无。

[mooncakejs]

jwt 带有效期， revoke 列表不需要很长，只需要缓存有效期内的 revoke list 就好了

[cloud107202]

最近刚搞了个类似的项目，就题目中的一些用语针对说一说当梳理一下，不一定很有条理：

1. jwt 可以吊销，至于要不要在 db 里存 token 列表可以看业务所用 token 的有效时长。很短的话(交易的分钟级，还有些数天情况的业务)用 redis 等基于内存的 cache 业足够了。以(userId, jwt, secret)这么个元祖的长度为例的话，cache 里存百万千万个数据一点都不是问题。有效期更长的话 db + cache 是一个很简单的方案。

2. jwt 如果选用 HS256 算法，加解密是对称过程，跟非对称型加密相比开销并不大。

3. jwt 相比随机字符串，带来的额外好处还是很明显的。签名后的 jwt 不可伪造，因为秘钥在服务端。比如在 payload 里写入你的全局 ID，这样能通过 gateway 的所有请求，到了后端各个微服务。微服务可以认为这个 token 是有效的，然后从 token 里解出 payload 确认你的真实身份，做一些额外的校验逻辑。另外 jwt 是标准格式，不但各大语言都有数个对应的实现，而且 payload 里面一些约定字段也都是标准化的，能被很多 gateway 的 plugin 所支持。比如 exp 表示过期时间，jti 避免重放攻击。还可以将一些权限 /scope 等自定义数据放到 payload 中，让 gateway 判断你这个用户被允许访问哪些 API。因为 payload 已经被 token 签名了，服务端知道 payload 有没有被篡改。

4. 4 楼的话 我能想象出的方案是，客户端带着 token 请求 server 的任一接口，如果返回 401 token 失效 /过期 这时客户端就可以强制登出，让用户重新进行登录获取新的 token (这也算客户端能知道 token 失效的一个例子吧)

[lookas2001]

@cloud107202 谢谢回答～

[lookas2001]

@mingqing jwt 包含信息所带来的代价就是传输成本会变高（就是长），另外，随机 token 怎么伪造（汗颜）

@mooncakejs 那如果对于一个能控制所有 token 情况下呢？服务器还是要存储所有的 token。（要不这么知道吊销哪一个）

[lookas2001]

@cloud107202
1 但是不也是需要存嘛。。所以在存储代价上跟随机 token 也是一样的嘛
3 随机 token 也不能伪造啊。在进入微服务也就是说（不知道说的对不对）在 gateway 的时候，gateway 是不是需要检测一遍 token 是否被 revoke 掉了对吧。这样的话不是还是需要去 db 或 cache （关系型或 kv 型）去查一遍，这样的话是不是就跟随机 token 的查询成本就一样了。jwt 是去 db/cache 查是否 revoke 掉了，随机 token 是去 db/cache 查是否存在顺便把数据拉回来
jwt 的确是标准，但是其是否是必要的这就是我所想要问的。如果要设计一个完美的 token 体系，jwt 所需要的各种成本跟随机 token 我认为是不相上下的，甚至说 jwt 有加解密，编解码的过程可能还比不上随机 token
4 这不是还是需要去与服务器通信一次嘛。。。（汗颜）

[lookas2001]

感谢 v2 上各位 dalao 们的意见，作为一个萌新，能获得如此多的讨论，感觉十分幸运。（果然还是 v2 能解决问题。。）

[mooncakejs]

@lookas2001 不需要存正常的 jwt token，只要存吊销的就好。
随机 token 的检验成本比较高，容易造成单点瓶颈。 jwt 在有效期内吊销列表并不多，查询效率高。

[lookas2001]

@mooncakejs 额，其实说存储正常的 token 的原因还是在于可以随时吊销不需要的 token
不过尽管这样，如果分开存储，revoke 的单独存一份还是确实可以减少查询开支的。
谢谢回答～