Spring Security의 인증과 인가

인가 처리 흐름

인가는 체인의 마지막 부근에 있는 AuthorizationFilter가 담당한다. 이 필터는 요청과 SecurityContext의 Authentication을 AuthorizationManager에 넘겨 접근 허용 여부를 판단한다. URL 단위 규칙은 authorizeHttpRequests로 선언하고, 서비스 계층에서는 @EnableMethodSecurity를 켠 뒤 @PreAuthorize 같은 메서드 보안 애너테이션(Annotation)으로 세밀한 규칙을 건다.

@Service
public class AdminService {

    @PreAuthorize("hasRole('ADMIN')")
    public void deleteMember(Long memberId) {
        // ADMIN 역할이 있어야 호출할 수 있다
    }
}

인가에 실패했을 때 미인증 사용자라면 AuthenticationEntryPoint가 401 응답이나 로그인 페이지 이동을 처리하고, 인증은 되었지만 권한이 부족하면 AccessDeniedHandler가 403 응답을 처리한다.

설정 코드 예시

Spring Security 6에서는 WebSecurityConfigurerAdapter 상속 방식이 제거되었고, SecurityFilterChain을 빈으로 등록하는 방식만 사용한다.

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .csrf(csrf -> csrf.disable())
            .sessionManagement(session ->
                session.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/auth/**").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated());
        return http.build();
    }

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

세션 없이 토큰으로 인증하는 REST API라면 위처럼 무상태 세션 정책을 쓰고 CSRF 방어를 끄는 구성이 일반적이다. 다만 브라우저 세션 기반 애플리케이션에서 CSRF를 끄는 것은 위험하므로, 인증 방식에 따라 판단해야 한다. 인가 규칙은 넓은 패턴보다 구체적인 패턴을 먼저 선언해야 의도대로 매칭된다는 점도 주의한다.

면접에서 이렇게 물어본다

• 인증과 인가의 차이를 설명하고, 401과 403 상태 코드가 각각 어느 경우에 반환되는지 말해 보라.
• DelegatingFilterProxy, FilterChainProxy, SecurityFilterChain의 관계를 설명해 보라.
• 폼 로그인 요청이 들어왔을 때 AuthenticationManager와 UserDetailsService를 거쳐 인증이 완료되는 과정을 설명해 보라.
• SecurityContextHolder가 스레드 로컬을 사용하는 이유와 그로 인한 주의점을 말해 보라.
• JWT 기반 인증을 Spring Security 필터 체인에 어떻게 통합할 수 있는지 설명해 보라.