针对你提出的三个关于单体OAuth2多角色架构的疑问，我结合实际项目经验给出以下分析和建议：

这种单体应用同时承担OAuth2 SSO客户端、资源服务器、Basic认证服务的设计，在初期快速落地阶段是可以接受的——它能快速覆盖内部测试（Basic）、API调用（Bearer Token）、前端UI登录（SSO）这三类场景，避免了初期服务拆分的复杂度。

但你提到的集成系统（如SalesForce）自带客户端行为的情况，确实暴露了当前设计的冗余问题：如果你的前端UI完全由外部系统托管，或者只需要纯静态页面渲染，那么单体里的@EnableOAuth2Sso配置就属于多余的耦合，不仅增加了维护成本，还可能引入不必要的会话管理逻辑。

从长期迭代角度看，这种多角色混合的单体架构会逐渐变得臃肿，不同认证模式的配置优先级（比如@Order注解）容易引发冲突，后续扩展新的认证规则也会变得棘手。

你发现的Bearer Token认证后创建会话、后续请求携带其他用户Token仍沿用原有会话的问题，是非常严重的安全风险，属于典型的会话固定+身份冒充漏洞。

问题根源 #

默认情况下，Spring Security的OAuth2资源服务器会创建HttpSession来缓存已认证的用户信息，当后续请求到达时，系统会优先读取已有会话的认证信息，而不会重新校验新的Bearer Token——这就导致只要会话未过期，攻击者拿到有效会话ID后，即使携带其他用户的Token，也能冒充原用户访问接口。

修复方案 #

• 强制资源服务器采用无状态模式：在OAuth2ResourceServerConfig的configure(HttpSecurity http)方法中添加会话管理配置，彻底禁止会话创建：

  http
      .requestMatcher(request -> {
          String auth = request.getHeader("Authorization");
          return (auth != null && auth.startsWith("Bearer"));
      })
      .authorizeRequests()
      .anyRequest().authenticated()
      .and()
      .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS); // 关键配置
  

• 隔离不同认证模式的会话：确保Basic认证、SSO的会话不会互相干扰，比如为不同认证模式配置独立的会话Cookie名称，避免跨模式的会话复用。

这两种方案都是可行的，分别适合不同的阶段：

方案一：Maven Profiles定制单体应用（过渡方案） #

通过Maven Profiles可以在构建时动态启用/禁用不同的认证配置，实现单体应用的多模式部署：

• 给每个配置类添加@Profile注解，比如：
  • WebSecurityConfig（Basic认证）添加@Profile({"test", "api"})
  • OAuth2ResourceServerConfig添加@Profile("api")
  • OAuth2SsoConfig添加@Profile("ui")
• 构建时通过指定Profile选择对应模式：

  # 构建纯API资源服务（启用Basic+Bearer认证）
  mvn clean install -Papi
  # 构建纯UI SSO客户端（仅启用SSO）
  mvn clean install -Pui
  

• 优点：无需拆分服务，适合快速迭代的过渡阶段；
• 缺点：配置仍耦合在单体中，长期维护还是会面临逻辑冲突的问题。

方案二：拆分为纯UI客户端和资源API独立应用（长期推荐） #

这是更符合微服务架构思想的方案，将职责彻底拆分：

• 纯UI客户端服务：仅保留@EnableOAuth2Sso配置，专注于前端页面的SSO登录、权限跳转，不提供业务API；
• 资源API服务：保留ResourceServerConfig和Basic认证配置，专注于业务接口的安全校验，采用无状态模式；
• 独立认证服务继续作为统一身份提供者，为两个服务提供认证支持。
• 优点：职责单一，配置清晰，避免认证模式冲突，便于独立扩容和维护；
• 注意点：拆分后需要做好跨域配置，确保UI客户端能正确携带Bearer Token调用API接口，同时要统一两个服务的权限规则。

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