Spring Security OAuth2自定义Token：getParameter与setAttribute选型咨询

问题1：哪种方案符合Spring Security/Java EE最佳实践？ #

从职责分离和解耦的角度，自定义OncePerRequestFilter将authorization code存入请求属性的方案更符合Spring Security的最佳实践。

Spring Security的核心设计思路是通过过滤器链处理请求的各个阶段，每个组件只负责单一职责：过滤器负责提取和预处理请求中的关键数据，而OAuth2TokenCustomizer的职责应该聚焦在Token的定制逻辑上，不应该耦合请求参数的提取细节。直接注入HttpServletRequest拿参数的方式虽然简单，但让Token定制组件依赖了请求参数的具体传递方式（比如参数名、是否是表单提交），违背了单一职责原则。

当然，如果是极简场景，直接拿参数的方式也能正常工作，但从长期维护和架构整洁性来看，过滤器方案更优。

问题2：使用属性而非参数的性能或架构权衡？ #

性能层面 #

两者几乎没有性能差异，都是请求生命周期内的内存操作，不会带来额外的性能开销。

架构层面 #

过滤器方案的优势：

• 解耦性更强：如果后续authorization code的传递方式发生变化（比如从URL参数改成JSON请求体），只需要修改过滤器的提取逻辑，OAuth2TokenCustomizer完全不需要改动
• 复用性更高：请求属性中的auth code可以被其他需要该数据的组件复用，不用重复编写参数提取代码
• 符合框架设计模式：Spring Security本身就在过滤器链中大量使用请求属性来共享上下文数据（比如认证后的Authentication对象），这种方式和框架的设计思路保持一致

直接拿参数的劣势：

• 耦合了请求参数的具体形式，后续需求变更时维护成本更高
• 让Token定制组件承担了不属于它的职责，代码职责不够清晰

问题3：是否有官方参考支持其中一种方案？ #

Spring Security官方文档中，在描述请求上下文传递时，明确推荐使用**请求属性（Request Attributes）**作为过滤器链内部组件间共享数据的标准方式。官方在处理认证流程时，也会将认证结果、用户信息等数据存入请求属性，供后续的拦截器、控制器或其他组件使用，这和过滤器方案的思路完全一致。

另外，在OAuth2相关的扩展场景中，官方示例也倾向于通过过滤器或认证转换器来预处理请求数据，再将处理后的数据传递给后续的Token定制或授权组件，避免直接在Token定制逻辑中依赖原始请求参数。

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