Spring Security架构中SecurityContext的作用及为何不直接用Authentication

在Spring Security中，我们通常这样获取当前用户的认证信息：

Authentication authentication = SecurityContextHolder.getContext().getAuthentication();

很多人会疑惑：为什么不直接让SecurityContextHolderStrategy直接存储/获取Authentication，非要多一层SecurityContext？下面从设计初衷和架构作用两方面解释：

一、为什么要引入SecurityContext？核心是扩展性与职责分离 #

如果直接让SecurityContextHolderStrategy操作Authentication，虽然初期代码更简洁，但会埋下两个隐患：

1. 限制未来功能扩展
   Authentication只负责封装用户的核心认证数据（用户名、权限、凭证），但安全上下文可能需要承载更多信息——比如后续要加多租户ID、认证会话的元数据、临时权限标识、甚至是OAuth2的令牌上下文等。如果当初设计成直接存Authentication，要加这些功能就得修改SecurityContextHolderStrategy的接口，所有实现类（比如ThreadLocalSecurityContextHolderStrategy、GlobalSecurityContextHolderStrategy）都得跟着改，成本极高。

而通过SecurityContext作为中间层，后续扩展只需要给SecurityContext加字段，完全不用动存储相关的代码，符合开闭原则。

2. 明确职责边界

• SecurityContextHolderStrategy的职责是管理上下文的存储介质：它只关心用什么方式存（ThreadLocal、全局变量、自定义存储），不关心存的内容是什么。
• SecurityContext的职责是封装安全上下文数据：它把Authentication和其他安全相关数据聚合成一个整体，提供统一的访问入口。
  这种职责分离让架构更清晰，代码维护性更强。

二、SecurityContext在Spring Security架构中的核心作用 #

简单说，SecurityContext是当前请求/线程的安全数据容器，作用主要有三个：

• 统一安全数据入口：把Authentication以及其他可能的安全元数据封装在一起，业务代码不用分散获取各种安全相关信息，只需要从SecurityContext里拿。
• 解耦存储与业务逻辑：业务层只需要通过SecurityContextHolder.getContext()获取上下文，不用关心这个上下文存在哪里（ThreadLocal、全局变量还是其他）——存储逻辑完全由SecurityContextHolderStrategy处理，业务和存储层彻底解耦。
• 支持上下文传递：在异步场景（比如Spring的@Async方法）中，SecurityContext可以被方便地传递到子线程，只需要配置对应的执行器（比如DelegatingSecurityContextAsyncTaskExecutor）。如果直接存Authentication，传递逻辑会和存储方式绑定，灵活性差很多。

补充：关于SecurityContextHolderStrategy的设计示例 #

你提到的两种Strategy实现，如果按照Spring Security的原始设计，它们存储的是SecurityContext而非直接存Authentication，比如ThreadLocalSecurityContextHolderStrategy的实际逻辑应该是：

final class ThreadLocalSecurityContextHolderStrategy implements SecurityContextHolderStrategy {
    private static final ThreadLocal<SecurityContext> contextHolder = new ThreadLocal<>();

    @Override
    public SecurityContext getContext() {
        SecurityContext ctx = contextHolder.get();
        if (ctx == null) {
            ctx = createEmptyContext();
            contextHolder.set(ctx);
        }
        return ctx;
    }

    @Override
    public void setContext(SecurityContext context) {
        contextHolder.set(context);
    }
    
    // 其他方法...
}

这样的设计下，不管SecurityContext后续怎么扩展，这些Strategy都不需要修改，完全符合面向抽象编程的思想。

内容的提问来源于stack exchange，提问作者fullstack.yang