Spring 将JWT存储在数据库中有意义吗？

我已经用Spring引导、Spring安全、OAUTH2和JWT作为身份验证令牌实现了一个基本的身份验证系统。它工作正常，但我在想，将JWT存储在数据库中并在每次有人使用它发出经过身份验证的请求时检查令牌是否存在是否有意义？我特别考虑了以下场景：用户在移动设备中进行了身份验证，但他们丢失了身份验证，因此他们希望取消对该设备的授权。然后，他们将能够发出一个操作，清除发给他们的用户id的令牌，并取消分配给他的所有令牌的授权。还有别的办法吗？我的想法是错误的还是过于复杂

---

这是为了保护将从移动应用程序调用的REST API。

您可以设置过期日期（对于移动应用程序，为1周）。 为用户添加一些自定义字段

refreshId

（您可以为此使用uuid）。 下一组在索赔参数（“iat”）下发布。 将

refreshId

存储到数据库中，并将其设置为索赔参数。

---

然后，每次验证令牌时，都应该检查令牌的“年龄”。如果超过一小时，您应该从DB加载数据并检查

refreshId

值，然后使用当前的“iat”值创建新令牌并将其发送到移动设备。当您需要停用令牌时，只需为数据库中的

refreshId

生成新值即可。一小时后，所有令牌都将不正确，因此用户需要再次登录每个设备。如果需要，您可以定制更多的解决方案

您可以将JWT存储在db中，但会失去JWT的一些好处。JWT的优点是不需要每次都检查db中的令牌，因为您可以使用加密来验证令牌是否合法。如果您必须在数据库中查找令牌，那么最好使用不携带信息的不透明令牌，并让服务器和数据库向您提供信息。另一方面，如果要在db中存储令牌，我不认为JWT对于您的令牌类型是一个坏的选择。正如您所说，如果您将令牌存储在db中，那么撤销有很多好处。这完全取决于您想要实现什么（更快的授权等，而不是按需撤销）

---

如果需要，您仍然可以将JWT与OAuth2一起使用，而无需在db中存储令牌。JWT有一个可配置的到期时间，您可以设置它——超过这个时间，它们就无效了。为了安全起见，访问令牌（无论JWT与否）通常应该是短期的。如果担心某人的手机被盗，并获得访问令牌，我认为解决方案是让这些令牌快速过期（30分钟？）。如果您使用的是oauth2，阻止某人继续使用该应用程序的方法是让真正的所有者在授权服务器上取消对移动应用程序客户端的授权，这样就不会有更多的访问令牌发出。

所以您认为我更适合使用oauth2（项目要求，需要与另一个API接口）默认令牌，将它们存储在数据库中并刮取JWT？对于这个例子，我真的不需要在令牌中存储数据（我这样做是为了访问一些常见的和定期访问的数据，但我真的可以不用它）。我有一个问题-我一直看到JWT用于身份验证。但它的主要优点是可以随身携带数据。但是要在站点上实现注销，需要有一个黑名单来检查jwt是否有效（因为没有办法仅在实时过期时将jwt标记为无效）。因此，正如这篇文章所说，你失去了JWT的一些好处。那么，为什么您仍然使用JWT，而只是使用db进行登录/注销呢？一旦有了黑名单，使用JWT有什么好处吗？@tcoulson，澄清一下。。。RP的“注销”并不一定意味着注销颁发令牌的授权服务器（AS），也不意味着以前颁发的访问令牌被列入“黑名单”（JWT与否）。“黑名单”访问令牌是一种选择（在oauth2规范之外），在我看来，它大大降低了选择JWT的价值。我所看到的JWTs被列入黑名单的唯一优势是，它比DB更容易通过检查令牌声明。黑名单的JWT也有缺点，比如每次呼叫的令牌大小加上DB检查的延迟。RP是什么？完全同意优势。我绕过了令牌大小的黑名单长度的一个问题，给令牌一个jti并保存唯一的密钥。但我仍然有一个问题，那就是每当有人进入我的应用程序时，我都会检查服务器。我也没有看到单独使用JWT进行授权的好解决方案。我仍然看到在JWT中传递用户详细信息的巨大用途，尤其是那些只是信息性的东西。感谢您的回复@sdoxsee抱歉没有定义术语@tcoulson。RP=依赖方（或客户）。我使用的是openid connect术语。这似乎是一个很好的方法——两全其美，仍然可以获得JWT的好处，即不需要检查数据库中的令牌，但可以撤销（不是立即撤销，但仍然可以撤销）。流氓用户（前雇员？）不会花很长时间造成破坏。我认为不应放弃立即撤销访问权的能力。