面经策

Spring Security 的整体架构是怎样的？核心机制是什么？ ​

  • 标签：Spring Security、认证授权、后端

🏛 业务架构师 ​

Spring Security 的整体架构一句话：基于 Servlet Filter 的责任链 + 认证授权两大机制的组合。

核心机制拆解：

  1. DelegatingFilterProxy + FilterChainProxy：Spring Security 以一组 Servlet Filter 接入 Web 容器（本质是 Filter 责任链模式），所有请求先过安全过滤器链再到业务代码；
  2. SecurityFilterChain：十几个安全过滤器按序执行（SecurityContext 持有、CSRF、认证、授权、异常处理），每个环节职责单一——这是"管道+切面"的经典架构；
  3. 认证（Authentication）：通过 AuthenticationManager（ProviderManager 委派多个 AuthenticationProvider）验证"你是谁"，产出 Authentication 对象（principal+credentials+authorities）存入 SecurityContext；
  4. 授权（Authorization）：FilterSecurityInterceptor（新版 AuthorizationFilter）按 URL 规则、方法级用 @PreAuthorize 按 SpEL 表达式判定"你能干什么"；
  5. 可插拔设计：认证方式（表单/JWT/OAuth2）、密码编码器、UserDetailsService 全部是接口扩展点——适配任何身份体系。

业务视角的评价：Spring Security 功能全但学习曲线陡，很多团队"能跑就绕着走"——我的看法是：金融、电商、SaaS 这类安全是底线的业务，它的过滤器链模型、CSRF/会话固定防护这些"默认安全"是买保险；轻量内部工具用 Sa-Token 这类国产轻方案也务实。关键决策：别手搓认证授权——安全代码自研的隐性缺陷成本远高于学习框架的成本。

🏗 系统架构师 ​

Spring Security = 基于 Servlet Filter 链的声明式安全框架，核心机制是**"一组有序过滤器 + SecurityContext"**两件套。

整体架构（三层）：

  • Filter 层（入口）：DelegatingFilterProxy 桥接 Servlet 世界与 Spring 容器，委托给 FilterChainProxy——它按请求匹配 SecurityFilterChain（可配置多条链，按路径/主机路由），链内过滤器各司其职（CORS → CSRF → 认证 → 授权 → ExceptionTranslationFilter → FilterSecurityInterceptor）；
  • 认证层：AuthenticationManager（通常 ProviderManager）编排多个 AuthenticationProvider（DAO 认证、LDAP、JWT、OAuth2 登录码等）——策略模式，认证结果产出 Authentication（主体 + 凭证 + 权限）；
  • 上下文与授权层：SecurityContextHolder（ThreadLocal 持有当前 Authentication）；方法级用 AOP（@PreAuthorize 切面），URL 级用 AuthorizationFilter。

一次请求的流程：Filter 链前置处理 → 认证（用户名密码/JWT 解析/OAuth2）→ 构建 Authentication 存入 SecurityContext → 授权检查（URL 规则或方法切面）→ 到达业务代码（随时 SecurityContextHolder.getContext() 取身份）→ 异常由 ExceptionTranslationFilter 统一转 401/403。

架构师视角的评价：过滤器链是典型的责任链 + 策略组合，可组合性强但默认链路深、调试门槛高；它的价值在"声明式安全"——规则集中配置、覆盖 Web 与方法两级、生态全（OAuth2/CAS/SAML/LDAP）。生产要点：多条链按业务分域（API 链关 CSRF、表单链开启）、SecurityContext 的跨线程传递是虚拟线程/异步场景的高频坑。

💻 全栈开发专家 ​

Spring Security 本质是一个「过滤器链 + 安全上下文」体系：核心机制是 **FilterChainProxy（DelegatingFilterProxy）挂进 Servlet 规范，内部由若干 SecurityFilterChain 串起一组 SecurityFilter，配合 SecurityContext（认证信息载体）和 AuthenticationManager（认证引擎）**完成 认证→授权 的流水线。

架构分层（自外向内）：

Http请求
 → DelegatingFilterProxy（Servlet 桥接）
   → FilterChainProxy（总入口，@Order(SecurityProperties.DEFAULT_FILTER_ORDER)）
     → SecurityFilterChain（按匹配规则选择，可多条）
       → SecurityContextPersistenceFilter/SecurityContextHolderFilter
       → HeaderWriterFilter → CorsFilter → CsrfFilter
       → UsernamePasswordAuthenticationFilter（表单登录）
       → BearerTokenAuthenticationFilter（JWT/OAuth2 资源服务器）
       → ExceptionTranslationFilter（译 401/403）
       → AuthorizationFilter（授权裁决，最后执行）
 → Controller

两大核心机制：

  1. 认证：AuthenticationManager（ProviderManager 组合多个 AuthenticationProvider）校验凭证，成功后 Authentication 存入 SecurityContextHolder（默认 ThreadLocal）；
  2. 授权：FilterSecurityInterceptor（旧）/ AuthorizationFilter（6.x+）执行 authorizeHttpRequests 规则；方法级再加 @PreAuthorize（AOP 代理）。

6.x 的最小配置：

java
@Bean
SecurityFilterChain chain(HttpSecurity http) throws Exception {
    http.authorizeHttpRequests(a -> a
            .requestMatchers("/api/public/**").permitAll()
            .anyRequest().authenticated())
        .formLogin(Customizer.withDefaults());
    return http.build();
}

排查问题的第一站永远是「打开 actuator 的 filters 端点或 DEBUG 日志看请求过了哪些过滤器」——搞清链路，一半的安全问题就定位了。