在服务总线后面验证过期的 JWT 令牌

Posted 2023-03-10

【中文标题】在服务总线后面验证过期的 JWT 令牌

【英文标题】：Validating an expired JWT token behind the servicebus

【发布时间】：2016-05-22 16:26:28

【问题描述】：

我有一个允许用户创建新资源的 Web API 服务，例如：POST /api/resource。然后服务将创建请求放在服务总线上并以HTTP 202 Accepted 进行响应。

后台进程从服务总线获取消息并调用数据访问层来创建资源。但是，为了实施访问控制，数据访问层需要知道用户是谁，以确定是否允许他/她创建该资源。 我无法将此授权逻辑移至前端 Web API 并为数据访问层使用受信任的子系统。

所以我的解决方案是获取数据访问层的访问令牌并将其与资源创建有效负载一起存储。但这提出了一个问题。由于消息可能会在较晚的负载下处理，因此令牌可能在后台进程尝试使用它时已过期。那个时候也没有办法更新令牌。

所以我想在后端层处理时放宽对令牌有效性的要求。如果令牌是有效的（受信任的颁发者等），除了过期时间之外，我希望验证中间件接受令牌。

但是没有办法配置System.IdentityModel.Tokens.Jwt 令牌处理程序来验证过期令牌。这可以在不编写我自己的令牌验证器的情况下完成吗？

我的方法错了吗？有什么可行的替代方案来解决这个问题？

【问题讨论】：

问题：当您将令牌添加到服务总线开始时，令牌是否有效（如已授权）？还是我误解了你的问题

@Nkosi 当然，令牌在 Web 服务获取时有效。但它可能会在工作服务使用它时过期。服务总线创建了时间解耦。消息可以在它放在服务总线上的同一秒或一个小时后处理。

对。因此即使令牌过期，与 JWT 关联的包含用户仍然可以在后端提取以进行访问控制。你对 JWT 的理解程度如何？我问是因为我的想法可能看起来很手动，您需要了解解码 JWT

我认为我对 JWT 的理解相当不错，但我不想编写自己的安全基础架构。

【参考方案1】：

JWT 处理程序具有可扩展点，允许您保留所有默认验证逻辑并仅覆盖您要自定义的方面 - 在本例中为过期验证。您可以通过自己的 TokenValidationParameters.LifetimeValidator 实现来实现。

【讨论】：

哦，这很酷。我没有意识到这一点。你有更多信息的链接吗？

查看github.com/Azure-Samples/… - 如果您想忽略有效性，您只需将 TokenValidationParameters 中的 ValidateLifetime 设置为 false。如果您想要自定义验证例程（例如，接受过期不超过 30 分钟的令牌），您可以按照答案中的建议实现 LifetimeValidator 的处理程序。

完美，这正是我想要的！

我很高兴它有帮助！这是否意味着我得到了赏金？ :)

是的，但赏金活动的最短持续时间为 24 小时。别担心！ ;)

【参考方案2】：

看看使用刷新令牌。 Auth0 has a good article 解释了背景以及如何使用它们，并附有一些示例代码。

【讨论】：

刷新令牌在这里不起作用。它们仅适用于机密客户端（Web 应用程序），但这些请求来自浏览器。即使它们来自机密客户端，Web API 也无法访问刷新令牌。