我以前使用过JWT，但是他们API不需要注销功能。
我需要为API的Android应用和SPA实现注销功能。当我查找它时，发现有两种方法可以实现。
JWT Token并称之为一天。 其背后的逻辑是，由于在服务器中不维护任何类型的会话，因此删除客户端的令牌就足够了。 但是仍然存在这样的可能性，即使令牌落入错误的手中，即使用户不再使用令牌，他们仍然可以使用令牌。
鉴于应用程序的设计合理且使用HTTPS，则发生这种情况的机会非常低，并且可以通过缩短令牌的有效时间来将其最小化。但就我而言，令牌的有效期为30天。
这解决了即使用户注销并停止使用令牌后令牌仍然可用的问题。
但是，这增加了一个麻烦，需要运行cronjob才能从黑名单表中删除过期的令牌。否则，该表最终将变得非常大。
这也有点违反使用JWT的观点。维护黑名单与维护会话非常相似。我们必须为每个请求运行一个附加的数据库查询。否，它的伸缩性很差。的用户数量增长了。需要列入黑名单的令牌数量也会增加（对于API来说，这将是一个更大的问题，例如像我这样的具有多个前端应用程序且令牌的有效期较长的人。）
然后我想到了第三种方法。
在用户表中添加jwt_secret行，该行存储随机生成的字符串。使用它来签名JWT Token，然后在每个请求上使用user id中的jwt payload来获取用户表单db（这不是一个额外的查询，无论如何我们都必须这样做）并进行验证使用用户jwt_secret的令牌签名。当用户注销时，我们更改了jwt_secret，这使那里的所有令牌都失效了。
起初，我认为这是一个很棒的解决方案，仅是要意识到在此设置中，如果用户注销一个设备或浏览器，则他/她将注销所有设备。
那么还有另一种选择吗？或一种修改上述任何方法来解决问题的方法。还是我在考虑这个问题，应该使用上述选项之一？
答案 0 :(得分：3)
对于注销（正如您所指出的那样，这是用户发起的操作），我认为您无需执行任何其他操作。如果用户以某种方式没有删除他的JWT，那就这样。他不会获得对自己已经拥有的权利的任何额外访问。
但是，您的问题似乎暗示着如何知道JWT有效的问题。再次，正如您所指出的，如果JWT某种程度上落入了不正确的人手中，那么可能就无法避免这种情况。但是，对于每个请求，您通常都会针对该JWT进行几种类型的验证，例如
我的意思是，如果您需要在服务器端跟踪发生注销的情况，则可能需要将其持久保存到数据库中。但是，我认为您不需要这个。