如何在Spring Boot中集成Spring Security实现基于内存与数据库的认证拦截？

Spring Security在Spring Boot项目中的集成并不复杂，但很多初学者会被它的自动配置行为迷惑：只要引入了依赖，所有接口立刻被保护起来，浏览器访问时弹出一个默认登录页，控制台还会打印一个随机密码。这种默认行为虽然能快速演示，但离真实项目还有很大距离。我们真正需要的是自己定义用户来源、密码加密方式以及哪些URL可以匿名访问、哪些必须登录。下面从一个空的Spring Boot工程开始，逐步完成内存认证和数据库认证两种典型场景的配置。

添加依赖与基础Security配置

首先在pom.xml中加入spring-boot-starter-security依赖。如果使用Gradle，写法类似。这个starter会自动引入Spring Security的核心过滤器和默认配置，应用启动后立即生效。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

启动应用后访问任意接口，Spring Security会重定向到/login页面，用户名默认是user，密码会在启动日志中打印。要覆盖这些默认行为，需要定义一个类型为SecurityFilterChain的Bean。在Spring Security 5.7之后的版本中，推荐使用组件式配置替代旧的WebSecurityConfigurerAdapter。下面是一个最基础的配置类，它关闭了默认的HTTP Basic认证，开启了表单登录，并允许所有请求匿名访问，我们先让应用恢复自由访问，后续再逐步收紧规则。

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable())
            .authorizeHttpRequests(auth -> auth
                .anyRequest().permitAll()
            )
            .formLogin(form -> form.disable())
            .httpBasic(basic -> basic.disable());
        return http.build();
    }
}

这个配置中，csrf.disable()只是为了方便测试，生产环境通常不建议全局关闭CSRF保护。另外，从Spring Security 6开始，authorizeHttpRequests中的Lambda表达式成为标准写法，旧的antMatchers方式已经被废弃。理解了基础骨架之后，接下来分别看内存和数据库两种用户来源如何接入。

基于内存的认证配置

内存认证适合学习测试或者用户数量极少的内部系统。它的核心是构建一个UserDetailsService实例，Spring Security在认证时会调用它加载用户信息。最常见的方式是使用InMemoryUserDetailsManager，它实现了UserDetailsManager接口，背后用一个Map存储用户。

下面创建一个UserDetailsServiceBean，并注册两个用户：一个普通用户，一个管理员。密码必须经过编码，不能直接存入明文。Spring Security强制要求使用PasswordEncoder，这里选用BCrypt编码器。

@Bean
public UserDetailsService userDetailsService() {
    UserDetails normalUser = User.builder()
            .username("zhangsan")
            .password(passwordEncoder().encode("123456"))
            .roles("USER")
            .build();

    UserDetails adminUser = User.builder()
            .username("admin")
            .password(passwordEncoder().encode("admin888"))
            .roles("ADMIN", "USER")
            .build();

    return new InMemoryUserDetailsManager(normalUser, adminUser);
}

@Bean
public PasswordEncoder passwordEncoder() {
    return new BCryptPasswordEncoder();
}

这里需要注意，User.builder()方法内部不会自动对密码编码，所以必须显式调用passwordEncoder().encode(...)。如果直接传入明文，认证时会因为编码不匹配而失败。BCrypt编码器每次生成不同的盐值，因此同一个明文密码两次编码的结果不同，这并不影响认证，因为匹配时Spring Security会使用matches方法做校验。

内存用户配置完成后，还需要在SecurityFilterChain中指定哪些URL需要认证。比如让/admin/**只允许ADMIN角色访问，/user/**允许USER和ADMIN角色访问，其余路径放行。同时启用表单登录，并指定登录成功后的跳转逻辑。

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .csrf(csrf -> csrf.disable())
        .authorizeHttpRequests(auth -> auth
            .requestMatchers("/admin/**").hasRole("ADMIN")
            .requestMatchers("/user/**").hasAnyRole("USER", "ADMIN")
            .anyRequest().permitAll()
        )
        .formLogin(form -> form
            .loginPage("/login")
            .defaultSuccessUrl("/home", true)
            .permitAll()
        )
        .logout(logout -> logout
            .logoutUrl("/logout")
            .logoutSuccessUrl("/login?logout")
            .permitAll()
        );
    return http.build();
}

这个配置中，/login和/logout都被设置为permitAll，否则用户连登录页都看不到。自定义登录页可以是一个简单的HTML表单，提交字段名必须是username和password，action指向/login，method为POST。如果使用默认登录页，则无需自己编写页面。

基于数据库的认证配置

真实项目中用户数据几乎都存放在关系型数据库里，Spring Security提供了JdbcUserDetailsManager来直接对接标准结构的用户表。默认情况下，它期望数据库中存在users和authorities两张表，字段结构如下：

CREATE TABLE users (
    username VARCHAR(50) NOT NULL PRIMARY KEY,
    password VARCHAR(100) NOT NULL,
    enabled BOOLEAN NOT NULL
);

CREATE TABLE authorities (
    username VARCHAR(50) NOT NULL,
    authority VARCHAR(50) NOT NULL,
    CONSTRAINT fk_authorities_users FOREIGN KEY(username) REFERENCES users(username)
);

如果使用这套默认表结构，配置非常简单：只需注入一个DataSource，然后创建JdbcUserDetailsManagerBean。密码字段必须存储BCrypt等编码后的值，不能存明文。下面代码中数据源使用Spring Boot自动配置的H2内存数据库，实际项目换成MySQL、PostgreSQL同样适用。

@Bean
public UserDetailsService jdbcUserDetailsService(DataSource dataSource) {
    JdbcUserDetailsManager manager = new JdbcUserDetailsManager(dataSource);
    // 可选：自定义查询语句以匹配自己的表结构
    // manager.setUsersByUsernameQuery("select username, password, enabled from sys_user where username = ?");
    // manager.setAuthoritiesByUsernameQuery("select username, authority from sys_role where username = ?");
    return manager;
}

如果项目中的用户表和角色表结构不同，可以通过setUsersByUsernameQuery和setAuthoritiesByUsernameQuery两个方法指定自定义SQL。查询结果必须包含固定的列名：用户查询返回username、password、enabled三列；权限查询返回username和authority两列。这样只需要保证SQL返回的列别名与Spring Security期望一致，底层表名和字段名可以任意。

数据库认证同样需要配置PasswordEncoder，Spring Security在比对密码时会使用这个编码器。因此在用户注册或者管理员重置密码时，必须使用同一个编码器对密码进行BCrypt加密后再写入数据库。下面是初始化脚本示例，插入两个用户和对应权限：

INSERT INTO users (username, password, enabled) VALUES
('lisi', '$2a$10$7JB720yubVSZvUI0rEqK/.VqGOZTH.ulu33dHOiBE8ByOhJIrdAu2', true),
('manager', '$2a$10$lH2M1z8uUYQdJp3sKa9F3uMBXqjUZ4yVf5R6oY2cG8H1CzTbWnK0S', true);

INSERT INTO authorities (username, authority) VALUES
('lisi', 'ROLE_USER'),
('manager', 'ROLE_MANAGER'),
('manager', 'ROLE_USER');

注意密码哈希值可以通过new BCryptPasswordEncoder().encode("你的明文")生成，不要直接复制网上现成的字符串，因为盐值不同不影响验证，但你需要确保这个哈希确实对应你的明文密码。启动应用后，使用lisi/对应明文即可登录。

认证拦截规则与常见问题

在配置好用户来源后，真正决定接口安全性的是authorizeHttpRequests中的规则。Spring Security按照规则声明的顺序进行匹配，第一个匹配到的规则生效。因此更具体的路径要放在前面，anyRequest()必须放在最后。例如：

.authorizeHttpRequests(auth -> auth
    .requestMatchers("/api/public/**").permitAll()
    .requestMatchers("/api/admin/**").hasRole("ADMIN")
    .requestMatchers("/api/user/**").hasAnyRole("USER", "ADMIN")
    .requestMatchers("/swagger-ui/**", "/v3/api-docs/**").permitAll()
    .anyRequest().authenticated()
)

这里anyRequest().authenticated()保证除了明确放行的路径外，所有其他请求都必须登录。如果有些静态资源如CSS、JS、图片也需要匿名访问，可以提前用requestMatchers指定。注意requestMatchers支持Ant风格路径匹配，比如/resources/**匹配所有子路径。

除了路径授权，Spring Security还经常需要处理跨域和CSRF。在前后端分离项目中，如果前端使用Cookie保存会话信息，那么CSRF保护是必要的；如果使用纯Token方案（如JWT放在请求头中），则通常可以关闭CSRF。此外，登录接口本身需要设置为permitAll，否则会出现无限重定向。例如使用JSON格式登录时，可以自定义AuthenticationFilter，但这些已经超出基础认证拦截的范畴，读者可以在掌握本文内容后进一步深入。

最后要强调的是，数据库认证和内存认证并不是互斥的，你完全可以在同一个应用中配置多个UserDetailsService，但Spring Security默认只会使用一个。如果需要同时支持多种来源，比如管理员在内存中、普通用户在数据库中，可以自己实现一个UserDetailsService组合两个来源，或者使用DelegatingUserDetailsService。理解这两种基础方式之后，再去学习OAuth2、JWT等高级主题会轻松很多。

Spring BootSpring Security认证拦截修改时间：2026-09-22 21:35:18