SecurityContext在分布式系统（如微服务）中如何传递？有哪些常见方案？

在分布式系统中，尤其是在微服务架构下，确保用户的安全上下文（SecurityContext）能够在各个服务间正确、安全地传递，是构建安全体系的核心。这主要解决了"一次登录，到处认证"的问题。下面这张流程图清晰地展示了两种主流方案的核心流程与关键组件。

下面我们详细解析这两种方案，以及一些进阶的异步场景处理方式。

这是目前最常用和推荐的方式，其核心思想是在系统的边界（API网关）完成认证，然后将必要的用户信息"下沉"到下游微服务。

工作流程：
1. 网关认证：客户端请求携带JWT到达API网关（如Spring Cloud Gateway）。网关负责验证JWT的签名和有效期。
2. 注入上下文 ：认证通过后，网关从JWT中提取关键用户信息（如用户ID、角色列表），并将其以可信的HTTP请求头 （例如 X-User-Id, X-User-Roles）的形式注入到转发给下游服务的请求中。
3. 下游服务重建上下文 ：下游微服务接收到请求后，通过一个自定义的过滤器（Filter） 来读取这些请求头，并据此自动构建 Authentication对象，最终将其设置到当前线程的 SecurityContextHolder中。这样，业务代码就能像在单体应用中一样，通过 SecurityContextHolder.getContext().getAuthentication()无缝获取当前用户信息。
优势：
- 性能高效：下游微服务无需重复进行JWT的密码学验证，只需解析请求头，减轻了服务负担。
- 关注点分离：认证逻辑集中在网关，微服务只需关注业务授权，架构更清晰。
- 安全性可控：网关与微服务间通常是安全的内部网络，通过请求头传递用户信息是可控的。

这种方式将JWT令牌本身作为安全上下文的载体在服务间传递。

工作流程：
1. 网关透传：API网关仅进行最基本的路由和JWT透传，不进行复杂的认证或信息提取。
2. 服务独立验证：每个微服务在接收到请求时，都需独立验证JWT的有效性，并从JWT的Payload中直接解析出用户信息来构建安全上下文。服务间的调用也会将JWT原样传递。
适用场景与注意点：
- 这种方式更符合"零信任"原则，即不默认信任内部网络，每个服务都进行验证。但它会带来更大的性能开销，因为每个服务都要做JWT验证。
- 为确保安全，服务间调用也需要使用HTTPS等安全通道来传输JWT，防止令牌被截获。

当系统涉及异步消息（如Kafka、RabbitMQ）或使用线程池处理任务时，由于会切换到新的线程，ThreadLocal中的 SecurityContext会丢失。此时需要额外的传播机制。

手动注入与提取 ：在发送异步消息或提交任务到线程池之前，需要手动将当前的安全上下文（如JWT或用户ID）提取出来，作为消息的一个属性（Header）嵌入。在消费端或工作线程中，再从消息属性中提取出安全信息并手动设置到新线程的 SecurityContextHolder中。
使用Spring Security并发工具 ：Spring Security提供了一系列强大的工具类来简化这个过程，例如 DelegatingSecurityContextTaskExecutor。它能够自动地将当前安全上下文传播给被执行的异步任务。对于Spring Integration等消息驱动场景，可以使用 SecurityContextPropagationChannelInterceptor等拦截器自动完成上下文的传播与清理。