一般来说最简单的答案是你不能撤销 JWT 令牌，但这根本不是真的。诚实的答案是，支持 JWT 撤销的成本足够大，在大多数情况下不值得，或者直接重新考虑 JWT 的替代方案。
话虽如此，在某些情况下，您可能需要 JWT 和立即令牌撤销，因此让我们了解一下它需要做什么，但首先我们将介绍一些概念。
JWT (学习 JSON Web 令牌 https://auth0.com/learn/json-web-tokens/）仅指定令牌格式，此撤销问题也适用于通常称为自包含或按值令牌的任何格式。我喜欢后一个术语，因为它与引用标记形成了很好的对比。
按价值代币- 相关信息，包括令牌生命周期，包含在令牌本身中，并且可以验证该信息是否来自可信来源（数字签名来救援）
通过引用标记- 相关信息保存在服务器端存储中，然后使用令牌值作为密钥获取该信息；作为服务器端存储，相关信息是隐式信任的
在 JWT Big Bang 之前，我们已经在身份验证系统中处理过令牌；应用程序通常会在用户登录时创建一个会话标识符，然后使用该标识符，以便用户不必每次都重复登录过程。这些会话标识符被用作服务器端存储的关键索引，如果这听起来与您最近读到的内容类似，那么您是对的，这确实属于引用令牌。
使用相同的类比，理解引用令牌的撤销是微不足道的；我们只需删除映射到该密钥的服务器端存储，下次提供该密钥时它将无效。
对于按值代币，我们只需要实现相反的操作即可。当您请求撤销令牌时，您会存储一些内容来唯一地标识该令牌，以便下次收到它时您可以额外检查它是否被撤销。如果您已经认为这样的东西无法扩展，请记住您只需要存储数据直到令牌过期，并且在大多数情况下您可能只存储令牌的哈希值，这样它就总是是已知尺寸的东西。
最后一点，为了将其集中在 OAuth 2.0 上，按值访问令牌的撤销目前尚未标准化。尽管如此，OAuth 2.0 令牌撤销明确指出，只要授权服务器和资源服务器都同意处理此问题的自定义方式，它仍然可以实现：
在前一种情况下（自包含的令牌），当需要立即撤销访问令牌时，可以使用授权服务器和资源服务器之间的一些（当前非标准化的）后端交互。
如果您同时控制授权服务器和资源服务器，这很容易实现。另一方面，如果您将授权服务器角色委托给云提供商（如 Auth0）或第三方组件（如 Spring OAuth 2.0），您很可能需要以不同的方式处理事情，因为您可能只能得到已经标准化的内容。
一个有趣的参考
本文解释了另一种方法：黑名单智威汤逊 https://auth0.com/blog/denylist-json-web-token-api-keys/它包含一些有趣的实践和模式RFC7523 https://www.rfc-editor.org/rfc/rfc7523#section-2.1
