请问HN：你对这个JWT撤销策略有什么看法？
我正在构建一个应用程序，并且不打算使用引用的令牌，因此选择使用JWT（JSON Web Tokens）。但是，有一个要求是管理员需要能够撤销用户会话，这就需要在数据库中存储JWT、它们的ID或某些哈希值，并增加额外的查找。对于一个用户来说，这意味着如果他们在多个设备上生成了多个JWT，就需要撤销他们可能生成的所有JWT，而我们并不知道具体要撤销哪些令牌。
我的解决方案是添加两个声明（id和sid），并在用应用程序密钥签署令牌之前，使用用户密钥对sid进行签名。
当令牌到达时，我首先用应用程序密钥进行验证。如果无效或已过期，我们返回401状态码。
如果有效，我会使用用户密钥验证sid，因为我现在知道它属于谁。
对用户密钥的额外查找带来的开销非常小，因为我们已经进行了预认证，可以视为业务逻辑。
因此，撤销所有用户会话只需更改用户的密钥即可。
你们对此有什么看法？有没有漏洞？
查看原文
I am building an application and I do not indent to use token by reference, so using JWTs. But there is a requirement that admins need to be able to revoke user sessions, which would require storing JWTs, their ids or some hash on the DB and add an extra lookup. Doing this for a user means revoking all JWTs they might have generated if they are using multiple devices, and we don't know which tokens to revoke.<p>My solution is to add 2 claims (id and sid) and sign sid with a user secret before signing the token with the app secret.<p>When a token comes in, I first validate it with the app secret. If not valid or expired, we return a 401.<p>If valid, I validate the sid with the user secret since I now know who it belongs to.<p>The extra lookup for the user's secret then adds minimal overhead because we've already pre authenticated and can be considered business logic.<p>Thus, revoking all user sessions requires simply changing the user's secret.<p>What do you guys think about this? Any holes?