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

[yamedie]

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

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

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

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

[ksco]

@Bramblex2 #32 请教个问题，核发的逻辑要怎么做？写个中间件，每个带鉴权接口都可以支持核发 Token 吗？

[xomix]

要传递 userid 就要利用用户基本信息做 hash 的 sgin，要用 jwt 就用 jwt，这两个一起传着走的是不了解认证机制吧。

[wfd0807]

你这个前端跟我们公司的前端完全不是一个水平啊

我们公司的客户端要求认证完成后返回 token 的同时，还要返回 userId，甚至所有 payload 里面的内容都要和 token 同级别返回

而每次请求的时候，还必须把 userId 传给接口，虽然服务端早特么不用 userId

[arrow8899]

尽量别去外包吧，去外包待过一段时间，里面的人水平参差不齐，讨论问题心累 :sad:

[jhhhh]

他这做法，没有给服务器降低什么压力，倒是给数据库造成了不小的压力，token 校验的时候

[unco020511]

跟我上一个项目遇到的后端一模一样;我看到接口文档问他为啥都要传 token+userId+loginName,在 header 里传 token 不就完了吗,他说避免每次去查...

[Bramblex2]

@ksco

1. 有且只有账户服务统一核发 token，任何域名下面的任何服务都只认这个 token 作为「用户身份认证」，不带任何权限。并且账户服务可能需要支持各式各样的登录。

2. 如果不需要集中式的权限管理，那么权限管理直接下放到各个业务服务来处理。如果需要集中式的权限管理，那么要做的是建立集中式的服务。其他服务需要验证权限的时候直去权限服务验证权限

3. 如果建立状态，由业务服务自己跟客户端建立状态不，自行维护

[abcbuzhiming]

@AlvaIM jwt 的安全问题在于从基础设计上来说，缺少安全设计的最后一环：主动失效。它无法直接吊销——要吊销必须在服务器保存状态，就失去了 jwt 本来的设计目的。当然，不是所有场合都需要如此高的安全性的

[Kilerd]

1. 并不是说用了 JWT 就不需要用数据库了， 不用数据库的话 black list 是没法设计的，到头来还是要去数据库（或者是 redis ） 查一遍是否在 black list 里面。
2. JWT 就是明文传 userId 进来的（如果你存了进去的话），验证靠的是 SECRETKEY 的 HMAC
3. SECRETKEY 和 PAYLOAD 的大小没有形成明显的量级，所以最影响性能的应该是 HMAC 的算法。
4. 验证 jwt 有这么耗时吗？之前用 nodejs 写过 jwt 的 demo，没有察觉到解码 jwt 的开销。 说实话，你能说出这样的话，证明你的水平其实也不高，demo 来测试消耗怎么看都不靠谱，而是应该通过专业的 benchmark 框架进行测试。

[lifeintools]

违法了 json web token 的初衷了。。。

[zr8657]

你没必要教他，心里知道他菜就行了，毕竟他又没给你交学费，你教他干啥？

[yamedie]

@Kilerd
1. 没有问题, 特殊需求下需要吊销 token 当然需要上数据库或者 redis;
2. jwt 有 decode 和 verify 两种方法, 这个区别我是知道的;
3. 我还是想知道 jwt 的密钥如果很长的话,会对验证 token 的开销造成很大影响吗? (我应该自己去实验一下, 打印一下毫秒数, 看看 cpu 负载..)
4. 我只是觉得以解码开销为理由很站不住脚, 如果 jwt 作为一个广为人知的解决方案, 在解码 /验证上存在很大 cpu 开销以至于在性能上导致 jwt 不可用, 那为什么还有这么多人在用 jwt, 另外我不是开发测试, 没有用过什么 benchmark, 最多只用过 puppeteer.

[g8287694]

我记得 jwt 里面就有 time 的字段啊，而且 jwt 本身也不是永久的吧，到期过期，重新申请不就行了

[luozic]

benchmark 一下？

[ResidualWind]

怼他

[linxl]

哈哈哈 骚操作啊, 果真是菜无关乎语言. 照他这样每次都传账号密码验证算了.

[Allianzcortex]

jwt 注销用户从前端 window.localStorage.removeItem( ) 就好...担心复制粘贴 token 到另一台电脑上只要设置 JWT 过期时间很短就可以满足大部分需求。如果一定要求权限秒生效那就不是 jwt 的初衷，JWT Blacklist 只是权宜办法... G 上搜"JWT logout" 有很多文章和 SO 上的讨论，这个问题是有最佳实践的( ：

[AlvaIM]

@yamedie verify 的目地是防篡改， 数据库对比字符串本身就防篡改了，这是其一， 验签是 CPU 开销而读数据库（或者是 redis ）是 iO 开销，CPU 开销不容易优化，而 IO 开销一旦异步的话很容易优化。但是 jwt 的签名只不过是排列一下字符串重新 sha1 一次再判断是否相等， 对于 java 来说开销可以忽略。
有一个原则可以思考一下， 如果前端的 webserver 很多，且可以扩展，就尽量考虑让前端的 server 多耗点 CPU，降低 IO。 如果前端机器少， 那么就考虑省点 CPU， 用 IO 来换。系统的任何优化都是要有数据指标的，你的整个系统内的 CPU 核数， 决定了系统的总处理能力， 而分布式系统内带宽是有限的，总 IO 处理能力是有限的，是耗 CPU 还是耗 IO， 应该由系统的结构和业务类型来决定， 而不是仅仅针对单个功能点来看。

[deepdark]

你是对的，他连 jwt 的应用场景都不知道

[jay4497]

我寻思着这不是就拿 JWT 来做了个普通 token 的生成么，传 userid 然后比对这个用户的 token 有什么问题么，怎么会随便改个 userid 就对别人账户为所欲为呢，token 会对不上吧？求指教。。。