5. Spring Security 6 버전 기준 이전 방식(WebSecurityConfigurerAdapter 사용)과 최신 방식(SecurityFilterChain 사용) 비교

Spring Security는 6 버전대로 올라가면서 WebSecurityConfigurerAdapter가 Deprecated 되었습니다. 이로 인해 이전에는 WebSecurityConfigurerAdapter를 상속받아 메서드를 오버라이딩하는 방식으로 보안 구성을 했지만, 최신 버전(6.1 기준)에서는 SecurityFilterChain과 관련된 @Bean을 직접 정의하는 방식으로 구성이 바뀌었습니다.

 

1. 예전 방식 (WebSecurityConfigurerAdapter 사용)

Spring Security 6.1 이전의 예시

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    // 1) HTTP 보안 설정
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                // /public/** 경로는 인증 없이 접근 허용
                .antMatchers("/public/**").permitAll()
                // 그 외 모든 요청은 인증 필요
                .anyRequest().authenticated()
            .and()
                // 폼 로그인 사용
                .formLogin()
                // 로그인 페이지 커스텀할 경우 .loginPage("/login") 등으로 지정
            ;
    }

    // 2) 인증(인메모리 사용자, DB 연결, LDAP 등) 관련 설정
    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth
            .inMemoryAuthentication()
                .withUser("user")
                    .password("{noop}password") // {noop}은 평문암호를 사용한다는 의미
                    .roles("USER")
                .and()
                .withUser("admin")
                    .password("{noop}password")
                    .roles("ADMIN");
    }
}

특징

1. WebSecurityConfigurerAdapter를 상속받은 뒤, configure(HttpSecurity http) 메서드를 오버라이딩하여 HTTP 보안 관련 설정을 한다.
2. configure(AuthenticationManagerBuilder auth) 메서드에서 사용자 정보를 등록하거나 인증방식을 설정한다.
3. 프로젝트에서 여러 클래스가 WebSecurityConfigurerAdapter를 상속받을 수 있으며, @Order 애노테이션 등을 통해 우선순위를 정하는 식으로 다중 보안 구성을 할 수 있다.

 

 

2. 최신 방식 (SecurityFilterChain 사용)

Spring Security 6.1 이상에서 권장되는 예시

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    // 1) SecurityFilterChain Bean 정의: HTTP 보안 설정
    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        http
            .authorizeHttpRequests(authorize -> authorize
                // /public/** 경로는 인증 없이 접근 허용
                .requestMatchers("/public/**").permitAll()
                // 그 외 모든 요청은 인증 필요
                .anyRequest().authenticated()
            )
            // 폼 로그인 사용
            .formLogin(Customizer.withDefaults());

        // 추가적으로 세션 관리, CSRF, 로그아웃 등 다양한 설정 가능
        return http.build();
    }

    // 2) UserDetailsService Bean 정의: 사용자 정보 관리
    @Bean
    public UserDetailsService userDetailsService() {
        // 인메모리 사용자 관리 예시
        UserDetails user = User
            .withUsername("user")
            .password("{noop}password")
            .roles("USER")
            .build();

        UserDetails admin = User
            .withUsername("admin")
            .password("{noop}password")
            .roles("ADMIN")
            .build();

        return new InMemoryUserDetailsManager(user, admin);
    }

    // 3) 비밀번호 인코딩 방식
    @Bean
    public PasswordEncoder passwordEncoder() {
        // 실제 운영에서는 BCrypt 등 안전한 인코더를 사용해야 함
        return NoOpPasswordEncoder.getInstance();
    }
}

특징

1. WebSecurityConfigurerAdapter 없이, 직접 SecurityFilterChain를 반환하는 @Bean을 등록해 HttpSecurity를 구성한다.
2. 사용자 정보는 UserDetailsService를 통해 주입하고, AuthenticationManager는 Spring Security가 내부적으로 자동 설정한다.
3. 이전 방식보다 명시적으로 Bean을 정의하기 때문에, 구성 요소 간 의존관계가 더 투명하고 모듈화된다.
4. 여러 개의 SecurityFilterChain을 정의해 경로별로 다른 보안을 적용할 수 있으며, 필터체인을 등록할 때에는 @Order를 통한 우선순위나 SecurityWebFilterChain등으로 세분화할 수 있다.

 

정리

• 이전 버전(WebSecurityConfigurerAdapter)
  • 상속을 통해 configure(HttpSecurity http), configure(AuthenticationManagerBuilder auth)를 오버라이딩하여 보안 설정을 구성했다.
  • 직관적이지만, Bean 주입이 아닌 상속 구조이기에 프로젝트 규모가 커지면 유연성이 떨어질 수 있고, 제한적인 부분이 존재했다.
• 최신 버전(SecurityFilterChain)
  • 명시적으로 @Bean들을 정의해준다.
  • 필터 체인(SecurityFilterChain), 사용자 정보(UserDetailsService), 패스워드 인코더(PasswordEncoder) 등을 각각 Bean으로 구성한다.
  • 설정이 더 모듈화되고 유연해진다.
  • Spring Security 설정 체계와의 통합도 더 쉽게 이뤄져, 향후 업데이트에도 대응이 용이하다.

즉, WebSecurityConfigurerAdapter를 상속받아 설정하던 방식에서 Bean 기반 설정 방식으로 변경된 것이 핵심이며, Spring Security의 확장성과 유연성을 높이기 위해 권장되는 방향으로 바뀌었습니다.