我们有一个使用Identity Server 3的微服务环境。通过授权http标头中的承载令牌将身份提供给http微服务，其中令牌是JWT。该JWT通常代表登录的最终用户，但有时也可以代表已通过客户端凭据流进行身份验证的系统用户。
这些微服务将消息发布在队列（RabbitMQ）上，以进行异步处理。当前，我们有一个使用这些消息的Windows服务。它使用客户端凭据作为系统用户进行身份验证，然后将auth标头中的JWT发送到其他http微服务。
我们希望维护在整个流程中发布消息的用户的身份，包括从队列中消费一条消息时以及该消费者调用其他微服务时在机器对机器（m2m）通信中。即，当服务A（随JWT一起提供）将消息发布到队列时，则Windows服务应该能够模拟服务A的JWT中表示的用户，并且应该能够在以下情况下提供代表该用户的JWT：致电服务B。
Service A (running as alice) --> RMQ
RMQ <-- Win Service (running as alice) --> Service B (running as alice)
只有具有正确声明的客户才能以这种方式模拟用户。
为了使JWT返回Windows服务，我应该使用哪个流程？在Identity Server 3中应如何实现？尽管我尚未尝试检查Win Service的客户端是否具有有效的模拟冒用，但我已经设法使用资源所有者流生成了JWT，并传入了虚拟的用户名和密码（覆盖AuthenticateLocalAsync）。还是应该是实现ICustomGrantValidator的自定义流程？也许可以使用客户端凭据流？
请注意，原始JWT可以随消息一起提供，也可以随用户ID本身一起提供。原始JWT可能已过期，这就是Windows服务必须以某种方式重新认证的原因。
我的理解是，您希望通过分布式架构传播经过身份验证的身份，该分布式架构包括通过RabbitMQ消息代理传递的异步消息。
[当您将消息发送/发布到RabbitMQ时，您可能会考虑在消息头中包含JWT，即类似于在调用受保护的HTTP路由的HTTP头中包含JWT的方式。另外，如果您感到有些懒惰，可以将JWT直接放在消息有效负载上。您的异步（Windows服务）使用者可以在通过JWT时对其进行验证，也可以仅在后续的HTTP请求中将其传递到“其他http微服务”的受保护路由。
我不确定您是否对“我应该使用哪个流程”存在疑问，因为大概用户已通过身份验证（通过OIDC / authN流程之一，例如身份验证代码授予，隐式，ROPC ...）而且您只是为了通过authZ目的通过分布式体系结构传播JWT ...
就发送自定义消息头而言，我已经使用RabbitMQ和MassTransit完成了此操作，但这是为了在异步消息代理操作之间进行（OpenTracing）跟踪ID传播。回购在GitHub here上-可能会给您一些有关如何实现此目标的想法...
[[edit]以下说明如下：
以下是我可以想到的一些选项-每个选项都有一些安全隐患：
offline_access到/ token上指定的作用域列表端点。然后，您可以将刷新令牌传递给异步（Windows服务）使用者，它将能够使用刷新令牌以获取新的访问令牌（如果先前的令牌已过期）（或每次仅获取一个新的令牌）。您可能需要考虑一些安全因素在走这条路之前请三思。