Spring Security：Authentication与Principal权限的一致性及数据源疑问

1. 默认实现与契约里的一致性保障机制 #

Spring Security的默认认证流程里，初始阶段会保证两者权限一致，但没有强制的契约约束：

• 像DaoAuthenticationProvider这类基于UserDetails的认证提供者，在认证成功后，会通过createSuccessAuthentication方法把UserDetails的权限直接同步到Authentication对象里——这是默认的初始同步逻辑。
• 但这种同步是单向且只做一次：认证完成后，如果你通过Filter、AuthenticationSuccessHandler或者其他方式给Authentication加权限（比如你提到的FOO权限），这个变化不会同步回UserDetails，毕竟多数默认的UserDetails实现（比如org.springframework.security.core.userdetails.User）都是不可变对象，而且框架也没设计反向同步的逻辑。
• 之所以不搞强制契约，核心是为了灵活性：Spring Security允许开发者根据业务场景动态调整权限，比如临时给某个请求加权限、或者根据用户所在的上下文增减权限，强制一致反而会卡死这些场景。

2. 权限的真实数据源到底是谁？ #

分两种场景看：

• 框架自身的权限校验：不管是@PreAuthorize注解、URL权限控制还是方法级权限校验，全都是以Authentication#getAuthorities()为准。框架里的权限拦截器、投票器这些组件，都是直接从SecurityContext里的Authentication对象拿权限来判断的。
• 业务代码里的自定义判断：如果你是用@AuthenticationPrincipal拿到UserDetails后自己判断权限，那用的就是UserDetails的权限。但这里要踩个坑：如果Authentication的权限被动态改过，两者就会不一致，导致业务判断和框架校验逻辑对不上——所以建议统一用Authentication的权限，别搞两套标准。

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