1. 项目概述：为什么我们需要CitySecurity这样的实战项目？

如果你正在构建一个现代化的Web应用，尤其是涉及多租户、多角色或者需要对外提供API服务的系统，那么身份认证与授权（Authentication & Authorization）绝对是你绕不开的核心议题。我见过太多项目，初期为了快速上线，用几个简单的过滤器（Filter）或者拦截器（Interceptor）草草处理登录，结果随着业务膨胀，权限模型变得一团乱麻，后期重构的成本高得吓人。Spring Security框架虽然强大，但其学习曲线陡峭，尤其是当它与OAuth2.0协议结合时，各种配置类、过滤器链、令牌端点常常让开发者感到困惑。

“CitySecurity项目实战指南”这个标题，精准地指向了Spring Security与OAuth2.0集成的实战场景。它不是一个简单的“Hello World”示例，而是暗示了一个具备一定复杂度的、可能模拟“城市”或“多租户”概念的综合性安全项目。通过这个项目，我们不仅要理解OAuth2.0的四种授权模式（授权码、密码、客户端、简化）在Spring Security中的实现，更要深入探讨如何基于这些基础，构建一个灵活、可扩展的权限管理体系。最近社区里热议的“Spring Security ACL数据权限”，正是这种深度需求的体现——它关乎到“用户A能查看城市A的数据，但不能查看城市B的数据”这类行级数据权限的控制，这恰恰是很多业务系统的核心痛点。

因此，CitySecurity项目可以看作是一个沙盒，让我们在一个相对完整的上下文中，去实践如何配置资源服务器、认证服务器，如何自定义用户详情服务，如何设计基于角色的访问控制（RBAC）乃至更细粒度的数据权限控制。接下来，我将以一个从业者的视角，拆解这个项目的核心构成、实现细节以及那些官方文档不会告诉你的“坑”。

2. 整体架构与核心组件选型

在动手写代码之前，理清架构和选型是避免后期返工的关键。一个典型的集成Spring Security OAuth2.0的系统，通常会采用资源服务器与认证服务器分离的架构，这在微服务场景下几乎是标配。但对于CitySecurity这样的项目，我们可能会从单体应用开始，逐步演进出分离的架构，以便于理解整个流程。

2.1 认证服务器（Authorization Server）搭建

Spring Security OAuth2.0授权服务器曾是 spring-security-oauth 项目的一部分，但在Spring Security 5.2之后，社区推荐的方式发生了变化。对于较新的Spring Boot项目（2.7+），我们更倾向于使用Spring Authorization Server，它是Spring官方提供的新一代OAuth2.0授权服务器实现，未来会更受支持。

核心依赖选择： 

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>
<!-- 使用Spring Authorization Server -->
<dependency>
    <groupId>org.springframework.security</groupId>
    <artifactId>spring-security-oauth2-authorization-server</artifactId>
    <version>1.1.1</version> <!-- 请使用最新稳定版 -->
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <scope>runtime</scope>
</dependency>

选择Spring Authorization Server而非旧的 spring-security-oauth2-autoconfigure ，主要是出于技术前瞻性和社区支持度的考虑。新的授权服务器配置方式更模块化，与Spring Security 5.x的集成更丝滑。

基础配置类设计： 授权服务器的核心是一个配置类，它需要继承 AuthorizationServerConfigurerAdapter （旧版）或使用 @Configuration 配合一系列DSL配置（新版）。以新版的Spring Authorization Server为例，我们需要配置客户端详情、令牌服务以及端点安全。

@Configuration
@EnableAuthorizationServer
public class AuthorizationServerConfig extends AuthorizationServerConfigurerAdapter {

    @Autowired
    private AuthenticationManager authenticationManager;

    @Autowired
    private DataSource dataSource;

    @Override
    public void configure(ClientDetailsServiceConfigurer clients) throws Exception {
        // 配置客户端信息，可以存储在内存或数据库
        clients.jdbc(dataSource); // 使用数据库存储客户端配置
        // 内存配置示例：
        // clients.inMemory()
        //        .withClient("city-client") // 客户端ID
        //        .secret(passwordEncoder().encode("client-secret")) // 客户端密钥，必须加密
        //        .authorizedGrantTypes("authorization_code", "password", "refresh_token") // 允许的授权类型
        //        .scopes("read", "write") // 授权范围
        //        .redirectUris("http://localhost:8080/login/oauth2/code/city") // 回调地址
        //        .autoApprove(true); // 自动批准范围
    }

    @Override
    public void configure(AuthorizationServerEndpointsConfigurer endpoints) throws Exception {
        endpoints
            .authenticationManager(authenticationManager) // 密码模式需要
            .tokenStore(tokenStore()) // 令牌存储方式
            .accessTokenConverter(accessTokenConverter()); // 令牌转换器（如JWT）
    }

    @Bean
    public TokenStore tokenStore() {
        // 使用JWT令牌存储，避免资源服务器每次校验都查询数据库
        return new JwtTokenStore(accessTokenConverter());
    }

    @Bean
    public JwtAccessTokenConverter accessTokenConverter() {
        JwtAccessTokenConverter converter = new JwtAccessTokenConverter();
        converter.setSigningKey("my-secret-key-123456"); // 签名密钥，生产环境需从配置中心获取
        return converter;
    }
}

这里的关键决策是使用JWT（JSON Web Token）作为令牌格式。相比于传统的随机字符串令牌（opaque token），JWT是自包含的，资源服务器无需每次请求都向认证服务器验证令牌有效性，只需用公钥验证签名即可，这大大提升了性能并降低了认证服务器的压力。但需要注意，JWT一旦签发，在有效期内无法直接撤销，通常需要通过设置较短的过期时间并结合黑名单机制来弥补。

2.2 资源服务器（Resource Server）配置

资源服务器负责保护我们的业务API。它的配置相对更简洁，核心是声明哪些路径需要什么范围的权限。

@Configuration
@EnableResourceServer
public class ResourceServerConfig extends ResourceServerConfigurerAdapter {

    @Override
    public void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
            .antMatchers("/api/public/**").permitAll() // 公开接口
            .antMatchers("/api/admin/**").hasRole("ADMIN") // 需要ADMIN角色
            .antMatchers("/api/user/**").hasAnyRole("USER", "ADMIN") // 需要USER或ADMIN角色
            .antMatchers("/api/city/**").access("#oauth2.hasScope('read') and hasRole('CITY_MANAGER')") // 组合条件：需read权限且是城市管理员
            .anyRequest().authenticated(); // 其他所有请求都需要认证
    }
}

这个配置体现了权限控制的层次性：从公开路径，到角色控制，再到更复杂的基于OAuth Scope和Spring Security角色的混合控制。 #oauth2.hasScope() 是Spring Security OAuth提供的SpEL表达式，用于检查令牌的授权范围。

2.3 数据模型与用户服务定制

CitySecurity项目通常会涉及用户（User）、角色（Role）、权限（Permission）以及可能的数据域（如City）。我们需要自定义 UserDetailsService 来从数据库加载用户信息。

@Service
public class CustomUserDetailsService implements UserDetailsService {

    @Autowired
    private UserRepository userRepository;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        com.yourdomain.citysecurity.entity.User user = userRepository.findByUsername(username)
                .orElseThrow(() -> new UsernameNotFoundException("User not found: " + username));

        // 加载用户角色和权限
        Set<GrantedAuthority> authorities = new HashSet<>();
        for (Role role : user.getRoles()) {
            authorities.add(new SimpleGrantedAuthority("ROLE_" + role.getName()));
            for (Permission permission : role.getPermissions()) {
                authorities.add(new SimpleGrantedAuthority(permission.getCode()));
            }
        }

        return new org.springframework.security.core.userdetails.User(
                user.getUsername(),
                user.getPassword(),
                user.isEnabled(), true, true, true, // 账户状态
                authorities
        );
    }
}

这里有一个非常重要的细节：Spring Security在角色判断时，默认会加上 ROLE_ 前缀。所以数据库中存储的角色名如果是 ADMIN ，在这里需要转换为 ROLE_ADMIN 。权限则通常直接使用字符串标识，如 city:read 、 city:write 。

3. OAuth2.0授权码模式实战流程详解

授权码模式是OAuth2.0中最安全、最常用的模式，适用于有后端的Web应用。我们来完整走一遍CitySecurity项目中授权码模式的集成流程。

3.1 客户端注册与配置

首先，需要在认证服务器上注册一个客户端。如上文配置，我们可以将其持久化到数据库 oauth_client_details 表中。一条典型的客户端记录包含：

  • client_id : city-web-app
  • client_secret : （加密后的字符串）
  • authorized_grant_types : authorization_code,refresh_token
  • scope : read,write
  • web_server_redirect_uri : http://localhost:8080/login/oauth2/code/city
  • autoapprove : false （需要用户手动授权）

3.2 发起授权请求

用户访问客户端应用（CitySecurity前端）时，被重定向到认证服务器的授权端点：

GET /oauth/authorize?
  response_type=code&
  client_id=city-web-app&
  redirect_uri=http://localhost:8080/login/oauth2/code/city&
  scope=read write&
  state=some_random_state_string

state 参数用于防止CSRF攻击，必须随机生成并在回调时验证。

3.3 用户认证与授权

认证服务器会检查用户是否已登录。如果未登录，则跳转到自定义的登录页面（通过继承 WebSecurityConfigurerAdapter 配置）。登录成功后，会向用户展示一个授权页面，询问是否允许“city-web-app”应用获取你的 read 和 write 权限。用户点击“允许”后，认证服务器生成一个授权码（authorization code），并将用户重定向回客户端指定的 redirect_uri ，并附上授权码：

http://localhost:8080/login/oauth2/code/city?code=AUTHORIZATION_CODE&state=some_random_state_string

3.4 用授权码交换访问令牌

客户端后端在收到授权码后，必须立即向认证服务器的令牌端点发起POST请求，用授权码换取访问令牌（Access Token）和刷新令牌（Refresh Token）。 这个请求必须由后端完成，绝不能在前端进行，因为需要传递客户端密钥（client_secret）。 

// 这是一个模拟的后端服务方法
public OAuth2AccessToken getTokenByAuthorizationCode(String authorizationCode, String redirectUri) {
    RestTemplate restTemplate = new RestTemplate();

    HttpHeaders headers = new HttpHeaders();
    headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);
    headers.setBasicAuth("city-web-app", "client-secret"); // 客户端ID和密钥

    MultiValueMap<String, String> params = new LinkedMultiValueMap<>();
    params.add("grant_type", "authorization_code");
    params.add("code", authorizationCode);
    params.add("redirect_uri", redirectUri);

    HttpEntity<MultiValueMap<String, String>> request = new HttpEntity<>(params, headers);

    ResponseEntity<Map> response = restTemplate.postForEntity(
            "http://auth-server:9000/oauth/token",
            request,
            Map.class
    );

    // 解析响应，获取 access_token, refresh_token, expires_in 等
    Map<String, Object> tokenResponse = response.getBody();
    // ... 将令牌信息存储到会话或安全上下文中
}

成功响应会返回一个JSON对象，包含 access_token 、 token_type （通常是 Bearer ）、 expires_in （有效期）、 refresh_token 以及之前授权的 scope 。

3.5 使用访问令牌访问受保护资源

客户端在获取到 access_token 后，即可在访问资源服务器的API时，在HTTP请求头中携带该令牌：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

资源服务器会验证令牌的签名、有效期和范围，并根据配置的权限规则决定是否允许访问。

实操心得：令牌存储策略 在客户端应用中，访问令牌的存储需要谨慎。对于传统的服务器端渲染应用，可以存储在HttpSession中。对于前后端分离的单页应用（SPA）， 不建议将访问令牌存储在LocalStorage或SessionStorage中 ，因为它们容易受到XSS攻击。更安全的做法是使用HttpOnly的Cookie来存储，或者使用Backend for Frontend (BFF)模式，由后端代理所有API请求并管理令牌。在CitySecurity项目中，如果前端是独立的，建议增设一个轻量的BFF层（如使用Spring Cloud Gateway或一个简单的Spring Boot应用）来处理OAuth流程和令牌管理。

4. 深度集成：实现数据权限（ACL）控制

当基本的角色权限（RBAC）无法满足“同一个角色，但只能操作自己所属城市的数据”这类需求时，就需要引入数据权限，即Access Control List (ACL)。Spring Security提供了ACL模块，但其配置复杂，性能在数据量大时可能成为瓶颈。在实际项目中，我们更常采用自定义实现。

4.1 数据权限模型设计

假设CitySecurity项目中，我们有 City （城市）和 Department （部门）实体。数据权限规则可能是：“城市管理员（ROLE_CITY_MANAGER）只能管理自己城市的数据”，“部门经理只能查看自己部门的员工”。

我们需要扩展权限系统，在传统的“角色-权限”基础上，加入“数据范围”的概念。

  1. 数据库表设计补充：

    • user_city 表：记录用户与城市的管辖关系（一个用户可能管理多个城市）。
    • data_permission_rule 表：定义数据权限规则。例如：
      id role_id resource_type condition_expression
      1 3 (CITY_MANAGER) com.example.City cityId in (${currentUser.cityIds})
      2 4 (DEPT_MANAGER) com.example.Employee deptId = ${currentUser.deptId}

    condition_expression 是一个SpEL表达式字符串，在执行时会根据当前用户上下文进行求值。

4.2 自定义权限评估器（Permission Evaluator）

Spring Security允许我们通过 @PreAuthorize 和 @PostAuthorize 注解，结合SpEL实现方法级别的安全控制。我们可以自定义一个 PermissionEvaluator 。

@Component("cityPermissionEvaluator")
public class CityDataPermissionEvaluator implements PermissionEvaluator {

    @Autowired
    private UserCityService userCityService;

    @Override
    public boolean hasPermission(Authentication authentication, Object targetDomainObject, Object permission) {
        // 判断用户对某个具体对象是否有权限
        if (targetDomainObject instanceof City) {
            City city = (City) targetDomainObject;
            List<Long> managedCityIds = userCityService.getManagedCityIds(authentication.getName());
            return managedCityIds.contains(city.getId());
        }
        // 其他实体类型的判断...
        return false;
    }

    @Override
    public boolean hasPermission(Authentication authentication, Serializable targetId, String targetType, Object permission) {
        // 在只知道对象ID和类型时判断权限（更常用）
        if ("City".equals(targetType)) {
            Long cityId = (Long) targetId;
            List<Long> managedCityIds = userCityService.getManagedCityIds(authentication.getName());
            return managedCityIds.contains(cityId);
        }
        return false;
    }
}

然后在全局方法安全配置中启用它：

@Configuration
@EnableGlobalMethodSecurity(prePostEnabled = true)
public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration {
    @Override
    protected MethodSecurityExpressionHandler createExpressionHandler() {
        DefaultMethodSecurityExpressionHandler expressionHandler = new DefaultMethodSecurityExpressionHandler();
        expressionHandler.setPermissionEvaluator(new CityDataPermissionEvaluator());
        return expressionHandler;
    }
}

4.3 在业务层应用数据权限

现在，我们可以在Service层的方法上使用注解进行精细控制：

@Service
public class CityService {

    @PreAuthorize("hasRole('CITY_MANAGER')")
    public City getCityById(Long id) {
        // 这个方法只有城市管理员角色可以调用
        return cityRepository.findById(id).orElse(null);
    }

    @PostAuthorize("hasPermission(returnObject, 'READ')")
    public City getCityDetail(Long id) {
        // 方法执行后，用返回值对象进行权限校验。如果用户无权查看这个具体的城市，将抛出AccessDeniedException。
        return cityRepository.findDetailById(id);
    }

    @PreAuthorize("hasPermission(#cityId, 'City', 'WRITE')")
    public void updateCity(Long cityId, CityUpdateDTO dto) {
        // 在方法执行前，根据参数cityId进行权限校验。
        // hasPermission会调用我们自定义的CityDataPermissionEvaluator.hasPermission(...)方法。
        cityRepository.update(cityId, dto);
    }
}

4.4 在数据访问层进行过滤（更优方案）

方法级别的注解虽然灵活，但需要在每个方法上添加。对于查询列表的场景，更高效的方式是在数据访问层（如JPA的Specification或MyBatis的拦截器）动态注入数据过滤条件。

例如，使用JPA Specification：

@Component
public class CityDataFilter {

    public Specification<City> filterByUserCities(Authentication authentication) {
        return (root, query, criteriaBuilder) -> {
            if (authentication == null || !authentication.getAuthorities().contains(new SimpleGrantedAuthority("ROLE_CITY_MANAGER"))) {
                // 如果不是城市管理员，可能返回空结果或所有数据（根据业务）
                return criteriaBuilder.conjunction(); // 1=1
            }
            List<Long> cityIds = userCityService.getManagedCityIds(authentication.getName());
            if (cityIds.isEmpty()) {
                return criteriaBuilder.disjunction(); // 1=0
            }
            return root.get("id").in(cityIds);
        };
    }
}

// 在Repository中使用
@Repository
public interface CityRepository extends JpaRepository<City, Long>, JpaSpecificationExecutor<City> {
}

// 在Service中调用
@Service
public class CityQueryService {
    public Page<City> getCitiesForCurrentUser(Pageable pageable, Authentication authentication) {
        Specification<City> spec = cityDataFilter.filterByUserCities(authentication);
        return cityRepository.findAll(spec, pageable);
    }
}

这种方式对所有查询自动生效，无需在每个查询方法上添加注解，减少了代码侵入性，是处理数据权限列表过滤的推荐做法。

注意事项：性能与缓存 频繁查询用户的数据权限范围（如 getManagedCityIds ）会对数据库造成压力。务必对此结果进行缓存。可以使用Spring Cache，将结果以 user:${username}:managedCityIds 为Key缓存起来，设置合理的过期时间（如5分钟）。同时，要确保在用户权限发生变更时，能及时清理或更新缓存。

5. 常见问题排查与安全加固实录

在实际集成Spring Security OAuth2.0和实现数据权限的过程中，我踩过不少坑。这里记录几个典型问题和解决方案。

5.1 令牌相关问题

问题1：获取令牌时报错 invalid_client 或 unauthorized_client 。

  • 排查步骤：
    1. 检查客户端ID（ client_id ）和密钥（ client_secret ）是否完全匹配数据库或内存配置中的记录，注意大小写。
    2. 检查客户端密钥是否已使用配置的 PasswordEncoder （通常是BCrypt）进行加密。在内存配置中直接写明文密码会导致错误。
    3. 检查请求令牌端点时， Authorization 头是否正确进行了Basic Auth编码。格式应为 Basic base64(client_id:client_secret) 。
    4. 确认该客户端配置的 authorized_grant_types 是否包含了当前使用的授权模式（如 authorization_code , password ）。

问题2：访问资源API时报错 Invalid token does not contain resource id (xxx) 。

  • 原因与解决： 资源服务器配置了 resource-id ，但颁发的JWT令牌中没有包含对应的 aud （受众）声明，或者不匹配。
  • 方案A（推荐）： 在资源服务器配置中移除资源ID校验（如果微服务间完全信任）。在 ResourceServerConfigurerAdapter 的配置中，不设置 resourceId 。
  • 方案B： 在认证服务器配置JWT转换器时，添加资源ID信息。 
    @Bean
public JwtAccessTokenConverter accessTokenConverter() {
    JwtAccessTokenConverter converter = new JwtAccessTokenConverter();
    converter.setSigningKey(signingKey);
    DefaultAccessTokenConverter accessTokenConverter = new DefaultAccessTokenConverter();
    DefaultUserAuthenticationConverter userAuthenticationConverter = new DefaultUserAuthenticationConverter();
    // 设置UserDetailsService，确保用户名能正确转换
    userAuthenticationConverter.setUserDetailsService(userDetailsService);
    accessTokenConverter.setUserTokenConverter(userAuthenticationConverter);
    converter.setAccessTokenConverter(accessTokenConverter);
    return converter;
}
// 并在客户端详情配置中指定resourceIds
// .withClient("client").resourceIds("city-resource")

问题3：JWT令牌过期后，如何实现无感刷新？

  • 流程设计：
    1. 前端在发起API请求时，如果收到401响应，应检查本地是否存有 refresh_token 。
    2. 如果有，则静默（不跳转登录页）向认证服务器的 /oauth/token 端点发起POST请求， grant_type 为 refresh_token ，并提供 refresh_token 。
    3. 认证服务器验证刷新令牌有效后，返回新的 access_token 和 refresh_token （可选，取决于服务器配置）。
    4. 前端用新令牌重试失败的请求。
  • 安全要点： 刷新令牌应有较长的有效期，但需与用户会话绑定。当用户主动登出或修改密码时，必须立即使该用户的所有刷新令牌失效。可以在数据库中维护一个令牌黑名单或版本号来实现。

5.2 权限与配置问题

问题4： @PreAuthorize(“hasRole(‘ADMIN’)”) 注解不生效。

  • 排查步骤：
    1. 确认配置类上已添加 @EnableGlobalMethodSecurity(prePostEnabled = true) 。
    2. 确认该配置类被Spring容器扫描到。
    3. 确认调用被注解方法的是Spring代理对象。在同一个类内部的方法A调用方法B，B上的注解会失效，因为调用未经过代理。这是Spring AOP的机制。
    4. 检查角色名称是否正确。Spring Security默认要求角色名以 ROLE_ 开头。在 UserDetailsService 中加载权限时，角色需要添加此前缀；但在注解中使用时，写 hasRole(‘ADMIN’) 即可，框架会自动补全。

问题5：自定义的 PermissionEvaluator 未被调用。

  • 排查步骤：
    1. 确认自定义的 PermissionEvaluator 已注册到 DefaultMethodSecurityExpressionHandler 中，并且该Handler被设置为方法安全表达式处理器（见4.2节配置）。
    2. 确认在SpEL表达式中使用的是 hasPermission 函数，且参数顺序和类型与 PermissionEvaluator 接口定义的方法匹配。
    3. 检查注解是否加在了Controller层？ @EnableGlobalMethodSecurity 默认只对Spring管理的Bean（如@Service, @Repository）生效。如果需要在Controller生效，需要额外配置 @EnableGlobalMethodSecurity(prePostEnabled = true, proxyTargetClass = true, securedEnabled = true) 并确保Controller也被Spring管理（如使用 @RestController ）。

5.3 安全加固建议

  1. 使用HTTPS： 在生产环境，OAuth2.0的所有端点（授权、令牌）以及资源服务器的API都必须使用HTTPS，防止令牌在传输中被窃取。
  2. 安全的JWT密钥管理： 签名密钥（ signingKey ）绝不能硬编码在代码中。应使用配置中心、环境变量或密钥管理服务（KMS）来注入。对于更严格的场景，考虑使用非对称加密（RS256），认证服务器用私钥签名，资源服务器用公钥验签。
  3. 限制令牌范围（Scope）： 遵循最小权限原则，只为客户端申请必要的Scope。不要滥用 all 或 * 。
  4. 设置合理的令牌有效期： access_token 建议设置较短（如30分钟）， refresh_token 可以设置较长（如7天）。短期的访问令牌即使泄露，影响窗口也较小。
  5. 防范CSRF和XSS： 在授权码模式中，必须使用并验证 state 参数。确保应用没有XSS漏洞，防止攻击者窃取存储在浏览器中的令牌。
  6. 完善的日志与监控： 记录认证授权相关的关键事件（如登录成功/失败、令牌颁发、权限校验失败），并设置告警，便于安全审计和异常发现。

6. 项目扩展与生产级考量

当CitySecurity项目从演示走向生产环境时，有几个关键方面需要进一步设计和优化。

6.1 多租户数据隔离的增强设计

对于真正的“城市”安全项目，数据隔离是重中之重。除了前述的数据权限过滤，在数据库层面也可以考虑物理或逻辑隔离。

  • Schema隔离（逻辑隔离）： 为每个租户（城市）使用独立的数据库Schema。在应用层，根据当前登录用户所属城市，动态切换数据源或Schema。可以使用 AbstractRoutingDataSource 实现动态数据源路由。这种方式隔离性好，但管理成本稍高。
  • 字段隔离（软隔离）： 所有租户的数据存在同一张表中，通过一个 tenant_id （或 city_id ）字段区分。这是最常见的方式。结合我们之前实现的数据权限过滤（在查询中自动添加 city_id = ${currentCityId} 条件），可以实现有效的逻辑隔离。关键在于，确保所有数据写入操作都正确设置了 tenant_id ，并且所有查询都经过了过滤。可以通过Hibernate拦截器或MyBatis插件自动注入 tenant_id 。

6.2 认证服务器的高可用与性能

  • 令牌存储集群化： 如果使用Redis存储令牌（ RedisTokenStore ），则需要搭建Redis集群，确保令牌状态的高可用和可扩展性。如果使用JWT，则无需集中存储，但需要考虑令牌注销问题（可通过短有效期和令牌黑名单解决）。
  • 客户端配置集中管理： 将 oauth_client_details 配置放在配置中心（如Spring Cloud Config, Apollo），支持动态刷新，避免重启服务。
  • 端点防护： 对 /oauth/token 等端点实施限流（如使用Spring Cloud Gateway或Sentinel），防止暴力破解密码或刷新令牌。

6.3 前后端分离场景下的安全适配

CitySecurity很可能采用前后端分离架构。此时，传统的Session-Cookie机制不再适用，需要调整安全策略。

  • 跨域问题（CORS）： 在资源服务器和认证服务器配置中，需要正确设置CORS策略，允许前端应用的域名进行跨域请求。 
    @Bean
public CorsFilter corsFilter() {
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    CorsConfiguration config = new CorsConfiguration();
    config.setAllowCredentials(true);
    config.addAllowedOrigin("https://your-frontend-app.com"); // 指定前端地址
    config.addAllowedHeader("*");
    config.addAllowedMethod("*");
    source.registerCorsConfiguration("/**", config);
    return new CorsFilter(source);
}
  • BFF模式实践： 如前所述，强烈建议引入BFF层。前端只与BFF交互，BFF负责与认证服务器通信获取令牌，并将令牌安全地存储在服务器端的Session中。前端通过Cookie（HttpOnly, Secure）维持与BFF的会话。这样，敏感的令牌完全不会暴露给浏览器，极大地提升了安全性。BFF还可以聚合后端多个微服务的API，简化前端调用。

6.4 监控与审计

  • 健康检查端点： 暴露Spring Boot Actuator的 /health 和 /info 端点，监控认证和资源服务的状态。
  • 自定义审计事件： 发布Spring的 ApplicationEvent ，如 AuthenticationSuccessEvent , AuthorizationFailureEvent ，并监听这些事件，将重要的安全日志（谁、在什么时候、做了什么、是否成功）记录到ELK或时序数据库中，用于事后审计和安全分析。

通过以上这些扩展，CitySecurity项目就能从一个学习Demo，演进为一个具备生产就绪能力的、安全可靠的身份认证与授权中心原型。整个实践过程的核心在于理解OAuth2.0协议流与Spring Security抽象模型之间的映射关系，并在灵活性与安全性之间找到恰当的平衡点。记住，安全没有银弹，持续关注社区动态（如Spring Authorization Server的更新），定期审查和更新安全配置，是每个开发者需要养成的习惯。

Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

ChatGPT、Codex与Plus：AI生成代码后，开发者应该检查哪些关键问题？

avatar AI编程社区
cover

毕设降维打击！用聚合平台搞定论文配图与格式校对实战指南

avatar AI编程社区

codex清理C盘 提示词

磁盘清理安全规范摘要 先扫描后操作：优先检查大目录、缓存文件（如AI模型缓存~/.cache/huggingface、Python/Node.js缓存）、下载/临时文件、重复备份、旧安装包、媒体文件等，但禁止直接操作WSL/Docker虚拟磁盘（仅列出大小）。 安全分级处理： A类（可删）：临时文件（如Temp目录）、日志、缩略图缓存等。 B类（可迁移）：大模型缓存、安装包、旧备份、媒体文件（需创

avatar AI编程社区