前几天不知道为啥，hacker news 上又的确对 jwt 集中攻击了一番

既然攻击的点是老生常谈，那回答自然也是老生常谈：
数据库里 user table 加入一个 timestamp，只有该 timestamp 之后的 jwt 才有效。

说实话，合理的使用场景也就用户改密码，之前所有的 token 全都失效。如果系统本身就是一个 passwordless sso，那这个应用场景根本就不存在。所以结论是，jwt 该咋用还是咋用，系统设计明白了根本不怕忽悠

【 在 hgoldfish 的大作中提到: 】
: 还是攻击 JWT 不能 invalidated，老生常谈了吧。
: 这个问题现在算是解决了吗？
: https://apibakery.com/blog/tech/no-jwt/
: ...................
--
FROM 122.58.115.*

这话说的，本来 session/jwt 也只管 authentication，到了 authorization 一步该访问数据库还是访问数据库。jwt 是一种自签名的机制，解决不了系统认为某些自己签发的信息不合法的问题，那自然需要额外的机制来验证。

在用户改密码这个场景下，jwt 依然完成了认证的第一步工作，所有非系统签发的认证都不会访问数据库。至于比较 timestamp，完全可以看成 authorization 的一部分，本来也要访问数据库，多一个 column 而已。

【 在 adamhj 的大作中提到: 】
: jwt流行起来本来就是为了做去中心化的身份认证吧，你再弄个timestamp出来，每次访问又要访问一下数据库，那我还要jwt干啥？
--
修改:eGust FROM 203.184.25.*
FROM 203.184.25.*

我想象力有限，啥场景只需要 authentication 不需要 authorization，能举个例子吗？

【 在 adamhj 的大作中提到: 】
: 我指的就是authentication的场景
: 原本只需要authentication的场景，因为你这个timestamp的加入，全都变成和authorization一样的负载了
--
FROM 203.184.25.*

啥业务也不干，仅仅像心跳包一样，造个新jwt，给登录时间续命的时候~~哈哈
【 在 eGust 的大作中提到: 】
: 我想象力有限，啥场景只需要 authentication 不需要 authorization，能举个例子吗？
--
FROM 123.120.189.*

再签新的 jwt 之前肯定要访问数据库的啊，用户还可能这期间被删了呢

【 在 beep 的大作中提到: 】
: 啥业务也不干，仅仅像心跳包一样，造个新jwt，给登录时间续命的时候~~哈哈
--
FROM 122.58.115.*