在服务总线背后验证一个过期的JWT令牌

Question

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

后台进程从服务总线中获取消息，并调用数据访问层来创建资源。然而，为了强制访问控制，数据访问层需要知道用户是谁，以确定是否允许其创建该资源。我不能将此授权逻辑移动到前端Web API并使用受信任的子系统来处理数据访问层。

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

因此，我希望放宽后端层处理令牌时令牌有效性的要求。如果令牌有效（信任发行者等），只是过期时间已过，我希望验证中间件能够接受令牌。

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

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

- MvdD

---

问题：当您首次获取要添加到服务总线的令牌时，这些令牌不是有效的（即已获授权）吗？或者我是否误解了您的问题。 - Nkosi

@Nkosi 当Web服务获取令牌时，该令牌是有效的。但是当工作器服务使用它时，它可能已经过期。服务总线创建了一个暂时的解耦。消息可以在放入服务总线的那一秒或一个小时后被处理。 - MvdD

好的。即使令牌过期，JWT 中包含的用户仍然可以在后端提取以进行访问控制。你对 JWT 了解得如何？我问这个问题是因为我的想法可能看起来比较手动，需要你知道如何解码 JWT。 - Nkosi

我认为我对JWT非常了解，但不想编写自己的安全基础设施。 - MvdD

Answer 1

JWT处理程序具有可扩展性点，允许您保留所有默认验证逻辑，并仅覆盖要自定义的方面 - 在这种情况下是过期验证。您可以传递自己实现的TokenValidationParameters.LifetimeValidator来实现此目的。

- vibronet

---

哦，那很酷。我不知道那个。你有更多信息的链接吗？ - MvdD

请查看以下链接：https://github.com/Azure-Samples/active-directory-dotnet-webapi-manual-jwt-validation/blob/master/TodoListService-ManualJwt/Global.asax.cs。如果您想要忽略有效性，请将TokenValidationParameters中的ValidateLifetime设置为false即可。 如果您想要自定义验证程序（例如，接受在30分钟之内过期的令牌），则可以按照答案中建议的方式实现LifetimeValidator的处理程序。 - vibronet

我很高兴能够帮到你！这是否意味着我可以得到赏金？ :) - vibronet

你的安全团队有理由关注这个问题。过期检查很重要。只有在确切知道自己在做什么以及可能使更改验证逻辑变得可行的缓解情况时，才能放松检查。这也是为什么通常你会使用自己的逻辑来覆盖默认的生命周期验证，而不是完全关闭过期验证——这只是为了验证 JWT 选项是否按预期工作。 - vibronet

当AAD支持委托令牌，如此处所述（http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html）时，我们只能允许组合令牌过期。目前，我们将不得不采取允许仅从同一子网调用数据访问服务的方法。 - MvdD

Answer 2

看看使用刷新令牌。Auth0有一篇很好的文章解释了背景和使用方法，并附有一些示例代码。

- Rex M

---

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