JWT 令牌撤销：中心化控制与分布式Kafka处理

【squids.cn】 全网zui低价RDS，免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等

令牌对于安全数字访问至关重要，但如果您需要撤销它们怎么办？尽管我们尽了最大努力，但有时代币可能会被泄露。这可能是由于编码错误、意外记录、零日漏洞和其他因素造成的。令牌撤销是现代安全性的一个重要方面，确保访问权限掌握在正确的人手中，并且将未经授权的用户拒之门外。在本文中，我们将探讨不同的方法（例如集中式控制和分布式 Kafka 处理）如何在确保系统和数据安全方面发挥重要作用。

访问/刷新令牌

我在本文中描述了有关使用 JWT 的更多信息。JWT 允许您消除使用集中式令牌存储并在每个微服务的中间件层中验证令牌。

为了减轻与令牌泄露相关的风险，访问令牌的生命周期被设置为等于一个较小的时间值（例如，15 分钟）。在最坏的情况下，令牌泄露后，它的有效期还有 15 分钟，之后它将exp小于当前时间，并且令牌将被任何微服务拒绝。

为了防止用户每 15 分钟注销一次，在访问令牌中添加了刷新令牌。这样，用户在身份验证成功后会收到访问令牌/刷新令牌对。当访问令牌的生命周期到期并且用户收到401 Unauthorized响应时，他们应该请求/refresh-token端点，将刷新令牌值作为参数传递，并接收新的访问令牌/刷新令牌对作为响应。之前的刷新令牌变为非活动状态。此过程降低了风险，并且不会对用户体验产生负面影响。

撤销

但在某些情况下，需要立即撤销令牌。这可能发生在金融服务中，或者例如，当用户想要从所有设备注销时，发生在用户的帐户中。在这里，如果没有令牌撤销，我们就无法做到这一点。但是，如何实现撤销 JWT 的机制呢？JWT 本质上是分散的并存储在用户的设备上？

集中式方法

最明显、最简单的方法是组织集中存储。这将是一个令牌黑名单，每个身份验证中间件层除了签名验证和令牌声明验证之外，还会去这个集中存储库检查令牌是否在黑名单中。如果是，请拒绝它。令牌撤销事件本身相当罕见（与授权请求的数量相比），因此黑名单会很小。此外，将令牌永远存储在数据库中是没有意义的，因为它们具有 exp 声明，并且在该值之后，它们将不再有效。如果您系统中发行的令牌的生命周期为 30 分钟，则您可以将已撤销的令牌在数据库中存储 30 分钟。

优点

• 简单性：与其他解决方案相比，此方法简化了令牌撤销管理。

• 细粒度控制：您可以细粒度控制撤销哪些令牌以及何时撤销。

注意事项

• 单点故障：集中式令牌撤销服务可能成为单点故障。您应该实施冗余或故障转移机制来减轻这种风险。

• 网络开销：微服务需要与中央服务通信，这会引入网络开销。考虑对延迟的影响并进行相应的设计。

• 安全性：确保中央令牌撤销服务安全实施并防止未经授权的访问。

这种方法提供了令牌撤销管理的集中控制和简单性，这对于某些用例来说是有益的，特别是当需要对撤销进行细粒度控制时。然而，它确实引入了一些网络通信开销，并且需要仔细考虑安全性和冗余性。

去中心化方法（基于 Kafka）

可以使用Kafka实现更先进的无单点故障的方法。Kafka 本质上是一个分布式且可靠的消息日志。它允许多个独立的侦听器和保留策略配置仅存储实际值。因此，可以将已撤销令牌的黑名单存储在 Kafka 中。当令牌需要撤销时，相应的服务会生成一个事件并将其添加到 Kafka。中间件服务包括一个 Kafka 侦听器，用于接收此事件并将其存储在内存中。授权请求时，除了验证令牌的有效性之外，无需联系中心化服务。撤销的令牌存储在内存中，在合适的数据结构中定位令牌是一个快速的过程（如果我们使用 HashMap，它将是O(1)）。也没有必要将令牌永远存储在内存中，并且应该在其生命周期结束后定期删除它们。

但是如果我们的服务重新启动并且内存被清除怎么办？Kafka 监听器允许您从头开始读取消息。当微服务恢复时，它将再次从 Kafka 中提取所有消息并使用实际的黑名单。

优点

• 去中心化：使用像 Kafka 这样的分布式消息代理可以让您以去中心化的方式实现令牌撤销。微服务可以独立订阅撤销消息，无需依赖中央机构。

• 可扩展性：Kafka 专为高吞吐量和可扩展性而设计。它可以处理大量消息，使其适合管理分布式系统中跨微服务的令牌撤销。

• 持久性：Kafka 将消息保留可配置的保留期限。这可确保撤销的令牌存储足够长的时间以覆盖其有效期。

• 弹性：该方法允许微服务处理令牌撤销，即使它们重新启动或经历临时停机。他们可以在恢复后简单地重新使用 Kafka 消息。

注意事项

• 复杂性：使用 Kafka 实施令牌撤销会增加系统的复杂性。您需要确保所有微服务正确处理 Kafka 主题、订阅撤销消息并管理内存中令牌撤销列表。

• 延迟：令牌被撤销的时间与微服务使用和处理撤销消息的时间之间可能存在轻微的延迟。在此窗口期间，仍可以接受已撤销的令牌。

• 可扩展性挑战： 随着系统的增长，跨多个微服务管理大量撤销消息和内存列表可能会变得具有挑战性。您可能需要考虑更高级的策略来分区和管理 Kafka 主题。

集中式令牌撤销方法和基于 Kafka 的方法之间的选择取决于您的具体用例、系统复杂性和偏好。集中式方法提供了简单性和细粒度的控制，但会带来网络开销和潜在的单点故障。基于 Kafka 的方法提供了去中心化、可扩展性和弹性，但实施和维护更加复杂。

结论

在数字安全至关重要的世界中，令牌撤销是一项关键的防御措施。无论您喜欢 Kafka 的集中控制还是分布式处理，核心信息仍然很明确：令牌撤销是强大安全性的重要组成部分。通过有效管理和撤销令牌，组织可以加强防御、保护敏感数据并确保访问权限掌握在正确的人手中。当我们结束关于令牌撤销的讨论时，请记住，主动安全措施是当今数字环境中必须采取的措施。因此，拥抱令牌撤销来保护我们互联世界中最重要的东西。

作者：Viacheslav Shago

更多内容请关注公号【云原生数据库】

squids.cn，云数据库RDS，迁移工具DBMotion，云备份DBTwin等数据库生态工具。