Spring Security默认过滤器链顺序疑问：UsernamePasswordAuthenticationFilter为何前置

已知信息 #

Spring Security提供的过滤器链基本顺序如下：

1. SecurityContextPersistenceFilter
2. LogoutFilter
3. UsernamePasswordAuthenticationFilter
4. ConcurrentSessionFilter
5. RememberMeAuthenticationFilter
6. AnonymousAuthenticationFilter
7. SessionManagementFilter
8. ExceptionTranslationFilter
9. FilterSecurityInterceptor

我重点关注ExceptionTranslationFilter的顺序。据我理解，ExceptionTranslationFilter的作用是捕获后续过滤器逻辑中出现的AuthenticationException和AccessDeniedException：前者由AuthenticationEntryPoint处理，后者由AccessDeniedHandler处理。我们可以通过如下代码在Security Config的HttpSecurity对象中自定义这两个处理器：

http.exceptionHandling()
        .authenticationEntryPoint(customEntryPoint)
        .accessDeniedHandler(customAccessDeniedHandler);

疑问点 #

我想了解为何上述过滤器链中UsernamePasswordAuthenticationFilter的顺序在ExceptionTranslationFilter之前。

UsernamePasswordAuthenticationFilter继承自AbstractAuthenticationProcessingFilter，在表单登录场景中通过用户名和密码完成认证。认证失败时会抛出AuthenticationException，默认由AbstractAuthenticationProcessingFilter注册（或自定义）的AuthenticationFailureHandler处理。

当然可以配置让该过滤器抛出的AuthenticationException由自定义的AuthenticationEntryPoint处理，但如果UsernamePasswordAuthenticationFilter默认位于ExceptionTranslationFilter之后，无需额外配置即可通过自定义的AuthenticationEntryPoint处理异常。

当通过如下代码注册自定义AuthenticationEntryPoint时，我期望认证过程中的错误能在此处处理，但实际并非如此。想知道Spring Security过滤器链顺序的历史原因：

http.exceptionHandling()
        .authenticationEntryPoint(customEntryPoint);

http.exceptionHandling()
        .authenticationEntryPoint(customEntryPoint)
        .accessDeniedHandler(customAccessDeniedHandler);

回答 #

1. 职责边界的清晰划分 #

Spring Security过滤器链的设计遵循**"认证前置，授权与全局异常处理后置"**的核心原则：

• UsernamePasswordAuthenticationFilter这类认证过滤器的核心职责是主动处理用户提交的认证凭证，它本身就内置了认证成功/失败的闭环处理逻辑（AuthenticationSuccessHandler/AuthenticationFailureHandler），属于认证环节的专属处理，不需要依赖全局异常过滤器。
• ExceptionTranslationFilter的定位是处理被动访问场景下的异常：比如用户未认证就直接访问受保护资源触发的AuthenticationException，或是已认证但权限不足的AccessDeniedException。这些异常并非来自主动提交凭证的认证流程，而是后续权限校验环节（如FilterSecurityInterceptor）的产物。

2. 历史设计的兼容性 #

Spring Security早期版本就确立了"认证过滤器先执行"的顺序，主要适配传统表单登录的场景需求：

• 传统表单登录是用户主动发起的认证请求，认证失败后需要直接返回登录页或针对性的错误提示，由AuthenticationFailureHandler处理更直接高效，不需要经过全局异常过滤器中转。
• 如果将认证过滤器放在ExceptionTranslationFilter之后，会导致主动认证的失败异常被全局处理器捕获，模糊了"主动认证失败"和"被动未认证访问"两种场景的边界，不符合早期设计的流程独立性要求。

3. 配置灵活性的保留 #

虽然默认顺序下认证失败不会走AuthenticationEntryPoint，但Spring Security提供了足够的配置空间满足自定义需求：

• 你可以自定义AuthenticationFailureHandler，在其中调用AuthenticationEntryPoint的逻辑，实现让认证失败异常走全局处理流程。
• 也可以手动调整过滤器链顺序，将UsernamePasswordAuthenticationFilter移至ExceptionTranslationFilter之后，但这会打破默认的职责划分，需要根据业务场景谨慎评估。

简言之，这个顺序是为了明确认证流程与全局异常处理的职责边界，同时兼容早期使用场景，并且保留了足够的自定义灵活性。

内容的提问来源于stack exchange，提问作者박찬준