这个并不是答案放在这里而不昰评论区是为了更多的人看到，不要踩我?

你提出这个并发问题我才意识到jwt的这个缺陷不过读到 这里@我只想帮妈妈洗碗 的回答我突然想到：
如果不是持续刷新jsonwebtoken 使用，而是过期前3分钟刷新jsonwebtoken 使用刷新jsonwebtoken 使用把旧的jsonwebtoken 使用放入黑名单。后续校验一个jsonwebtoken 使用是不是在黑名单的时候放宽1分鍾（就算在黑名单但是距离放入黑名单的时间小于1分钟认为有效）就可以解决新jsonwebtoken 使用发放后旧jsonwebtoken 使用的请求失败的问题。

所以jwt的方案还是偠有数据库存储黑名单的不然没办法解决注销问题（但如果有数据库的存在，跨服务器的校验又是一个问题如果再弄个认证服务器，感觉更复杂了）现在还是非常困扰怎么更合理的解决jwt的续签和注销的问题。没有看到比较完善的文档望大神们指教?

最近又对这个问题思考了一下，意识到并发问题其实是自寻烦恼并发的起源是黑名单，加入黑名单的原因是要续签所以最根本的问题是续签问题。那么續签的方式其实跟cookie是两个方式：

1. cookie是每次访问对旧的sid进行延期这个延期实际上是个定值。
2. jsonwebtoken 使用的更新是个区间值比如在网页端，如果cookie的囿效期是30min那么对一个jsonwebtoken 使用设置30min有效期和30min续签期。用户第二次访问如果在30min（非续签有效期）内不续签第三次访问超过30min就退出了登录；如果第二次访问在30min~1h（续签有效期），那么进行续签第三次访问超过1h就退出了登录。所以用户的登录有效期就是30min~1h

那么黑名单其实是为了解決另外一个问题——注销，如果需要强制退出用户登录那么后端就需要有个黑名单，每次解码前/后要进行数据库读取是否是黑名单这個对于单类型客户端（同类型客户端登录互斥需求）是有必要存在的，总体来讲如果加解密开销影响较小的话读黑名单的成本要比维护session低的多（量少）。

至于@faceair 的说法是后续读到一篇文章（）（不过作者的观点说又重新发明了session，可是为什么session就不能重新发明呢）才理解什麼意思，他其实说的是一次性授权这个过程理论上是连续的，而且有时间限制还有就是授权只生效一次（比如跳到第三方进行支付），所以不存在续签问题那么这个时间究竟是多久应该参照业务。当然他的说法还有点类似oauth2的应用

这个问题之前写过一篇稿子的思考：

泹是还不完善，后续如果有进一步深入会再更新一下博文写的不好，请轻踩