前同事把 jwt token 存在 sql 里，做法是不是有问题？

[yamedie]

在一个公众号外包项目里，与前同事不期而遇，他后端我前端。jwt 竟然被这样应用，想问：

1、这种使用姿势好处在哪里？感觉如果不验证 token 只读库比对的话，也许自己生成个 uuid 与 userId 做关联就可以了，为什么要用 jwt ？

2、验证 jwt 有这么耗时吗？之前用 nodejs 写过 jwt 的 demo，没有察觉到解码 jwt 的开销。

3、是否 secret 写的简短一些，token 就会短一些，解码耗时就少一些？

[xxxy]

你是对的

[tt67wq]

这个后端是真的菜！

[justfindu]

解码损失几乎可以忽略, 如果需要黑名单就需要缓存 jwt.

[jaskle]

jwt 黑名单是真的恶心

[dk7952638]

不懂瞎 JB 用的典型，jwt 对他而言可能只是因为很帅~

[KuroNekoFan]

还是 cookie session 好

[yamedie]

细思极恐的是：这个项目 [还] 这么做。

他走以前公司项目就是这样用 jwt 的，现在仍是。所有“我的订单 /我的某某列表”接口都需要传入 userId，jwt 形同虚设，只作为合法登录用户的凭证，接口随意篡改 userId 就能看到其他人的信息。

为此后端们研制了一种接口入参签名，把所有入参用 sha1 之类的摘要算法算出一个签名，追加到入参里，服务端检验入参有没有被篡改过。问题是前端需要把 sha1 的密钥写死在代码里。我对这种自己骗自己的行为表示过鄙视，劝过，无效。现在接口仍然这样传，累觉不爱。

[xuanbg]

这个后端对安全简直是一无所知，前端传的 userId 你也敢信？如果是 uuid 还好点，毕竟不好猜。自增 id 就等着哭吧，我随便换一个，就能对别的用户的数据为所欲为了。

[yamedie]

@xuanbg 你说对了是自增的，从 1 开始😅

[greatsir]

干他

[vance]

他原 JWT 为什么会出来都搞不懂，这样用的话

[xuanbg]

@yamedie 我一后端表示：这个参数验证完全是形同虚设，不说密钥能看得到，就是直接改了数据让你合法地传回去又有何难。

作为后端，基础的三不信还是要有的。三不信是：
1、前端的数据不可信
2、第三方的文档不可信
3、产品经理的承诺不可信

[ytmsdy]

@xuanbg 哈哈哈哈，精辟！

[cnnblike]

@xuanbg 大哥这三不信深得我心

[frantic]

这样的人又菜又自己为是，对自己的水平一无所知，遇到过很多次。

[leo108]

外包项目还在考虑性能问题，真是良心（

[feilaoda]

他的理解是错的

[ViewerBuc]

哈哈，他连为什么用 JWT 都不知道

[way2create]

典型的做都没做好就考虑性能 还搞错了

[ksco]

如果项目负责人不懂技术，你可以将此事类比成一些通俗的例子说给他听听。

........或者就干脆退出这个项目吧。不要跟这种人共事，到时候出了问题说不定还要把锅推到前端头上呢