Spring Security中AuthenticationEntryPoint与AccessDeniedHandler的差异及设计原因

虽然这两个组件的方法定义看起来类似，但它们处理的是完全不同的安全场景，拆分设计是为了贴合Spring Security的认证-授权流程模型，同时满足职责单一、扩展性和流程适配的需求，具体原因如下：

• 场景与上下文的本质差异

  • AuthenticationEntryPoint 处理的是未认证用户访问受保护资源的情况：此时用户还没有经过任何认证流程，系统需要引导用户完成认证（比如跳转登录页面、返回401 Unauthorized响应、触发OAuth2授权流程等）。
  • AccessDeniedHandler 处理的是已认证用户权限不足的情况：用户已经通过了认证，但当前请求的资源超出了其权限范围，系统需要返回权限不足的提示（比如跳转无权限页面、返回403 Forbidden响应等）。
    两者的触发时机和上下文完全不同，一个是"用户没登录"，一个是"用户登录了但没权限"，拆分后逻辑边界更清晰。

• 遵循单一职责原则
  把两种不同的异常处理逻辑拆分为独立组件，每个组件只专注于自己的职责：EntryPoint负责"启动认证流程"，Handler负责"处理授权失败"。这种设计让代码更易维护、测试和替换，比如你可以单独替换EntryPoint来适配不同的认证方式，而不影响授权失败的处理逻辑。

• 流程适配与扩展性需求
  在Spring Security的过滤器链中，AuthenticationEntryPoint 是在认证过滤器（比如UsernamePasswordAuthenticationFilter）之前触发，而AccessDeniedHandler 是在授权过滤器（比如FilterSecurityInterceptor）之后触发。拆分设计让它们能更好地嵌入到对应的流程节点中。
  同时，两者的扩展方向不同：EntryPoint需要支持多种认证协议的引导逻辑（表单、Basic、OAuth2等），Handler需要支持根据用户角色、资源类型返回不同的授权失败响应，拆分后各自的扩展不会互相干扰。

• 默认实现的针对性
  Spring Security提供的默认实现也体现了这种差异：

  • LoginUrlAuthenticationEntryPoint 会跳转登录页面，这是未认证场景的专属逻辑；
  • AccessDeniedHandlerImpl 默认返回403 Forbidden响应，这是授权失败场景的标准处理。
    如果合并成一个Handler，默认实现会变得复杂，无法兼顾两种场景的需求。

内容的提问来源于stack exchange，提问作者user18560558