HackerNews中文版

我正在构建一个应用程序，并且不打算通过引用使用令牌，因此选择使用JWT（JSON Web Tokens）。但是有一个要求是管理员需要能够撤销用户会话，这就需要在数据库中存储JWT、它们的ID或某些哈希值，并增加额外的查找。对一个用户进行此操作意味着撤销他们可能在多个设备上生成的所有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.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.When a token comes in, I first validate it with the app secret. If not valid or expired, we return a 401.If valid, I validate the sid with the user secret since I now know who it belongs to.The extra lookup for the user's secret then adds minimal overhead because we've already pre authenticated and can be considered business logic.Thus, revoking all user sessions requires simply changing the user's secret.What do you guys think about this? Any holes?

请问HN：你们对这个JWT撤销策略有什么看法？