Spring Security中Authorization Manager与AccessDecisionManager的区别及交互方式

一、核心区别 #

• 版本与定位差异
  AccessDecisionManager是Spring Security 5.7版本之前的核心授权决策组件，属于传统「投票式授权模型」的核心角色；而Authorization Manager是5.7版本后官方推出的新一代授权组件，作为统一的授权入口，旨在替代AccessDecisionManager、MethodSecurityMetadataSource等老组件，简化授权流程设计。

• 决策模型不同

  • AccessDecisionManager基于投票机制工作：需要配合AccessDecisionVoter投票器和ConfigAttribute权限元数据，多个投票器对当前请求/方法的权限进行投票后，由AccessDecisionManager汇总投票结果，最终决定是否允许访问。
  • AuthorizationManager采用单一决策模型：直接接收Authentication（当前认证用户）和AuthorizationContext（包含请求、方法等权限判断所需的元数据），直接返回AuthorizationDecision（授权通过/拒绝的结果），逻辑更内聚，无需拆分投票器和决策器。

• 扩展性与灵活性
  AuthorizationManager支持Lambda表达式自定义逻辑，代码更简洁，示例：

  AuthorizationManager<HttpServletRequest> manager = (auth, context) ->
      new AuthorizationDecision(auth.getAuthorities().contains(new SimpleGrantedAuthority("ADMIN")));
  

  而AccessDecisionManager的自定义需要分别实现投票器和决策器，步骤繁琐，需适配投票模型规则。

• 适用场景范围
  AccessDecisionManager仅适配老版本的Web安全拦截（FilterSecurityInterceptor）和方法安全（MethodSecurityInterceptor）；AuthorizationManager则覆盖了新版本的FilterChain授权、方法安全、OAuth2资源服务器授权等全场景，是官方推荐的标准授权方案。

二、二者的交互方式 #

在Spring Security的版本过渡和兼容设计中，二者的交互主要通过适配器实现：

• 老组件适配新流程：如果项目仍在使用AccessDecisionManager，可通过AuthorizationManagerDelegatingAccessDecisionManager将其包装为AuthorizationManager，让新版本的授权流程（如新版FilterSecurityInterceptor）能调用老的决策逻辑。
• 新组件复用老逻辑：自定义AuthorizationManager时，若想复用原有的投票器逻辑，可以在AuthorizationManager的实现内部调用AccessDecisionManager的决策方法，将老的投票机制封装到新组件中。
• 新版本默认无直接交互：Spring Security 5.7+的默认配置中，官方已经用AuthorizationManager完全替代了AccessDecisionManager的角色，二者不会直接交互，仅在手动配置兼容模式时才会产生关联。

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