SecurityConfig 클래스

SecurityConfig

 

SecurityConfig는 스프링 시큐리티의 인가 및 설정을 담당하는 클래스인데요. Security Config 구현은 스프링 시큐리티의 세부 버전별로 많이 다릅니다! 저는 스프링 시큐리티 6.2.1 버전으로 구현했어요.

자주 접할 수 있는 버전에 대한 구현 차이는 아래 영상을 통해 확인할 수 있습니다.

https://youtu.be/NdRVhOccuOs?si=FufI38WMhTs3TVr8

Security Config 클래스 기본 요소 작성

시큐리티 JWT 구현을 위한 Config 클래스의 일부분을 작성할 예정입니다. 먼저 기본적인 설정만 진행하고 시리즈를 진행하며 커스텀 필터 요소들을 추가 구현할 예정입니다.

SecurityConfig

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {

				//csrf disable
        http
                .csrf((auth) -> auth.disable());

				//From 로그인 방식 disable
        http
                .formLogin((auth) -> auth.disable());

				//http basic 인증 방식 disable
        http
                .httpBasic((auth) -> auth.disable());

				//경로별 인가 작업
        http
                .authorizeHttpRequests((auth) -> auth
                        .requestMatchers("/login", "/", "/join").permitAll()
												.requestMatchers("/admin").hasRole("ADMIN")
                        .anyRequest().authenticated());

				//세션 설정
        http
                .sessionManagement((session) -> session
                        .sessionCreationPolicy(SessionCreationPolicy.STATELESS));

        return http.build();
    }
}

 

BCryptPaasswordEncoder 등록

SecurityConfig

@Bean
    public BCryptPasswordEncoder bCryptPasswordEncoder() {

        return new BCryptPasswordEncoder();
    }

모든 비밀번호는 해시처리가 되어야 하기 때문에 미리 선언해줍니다.

 

그리고 JWT를 통한 인증/인가를 위해서 세션을 STATELESS 상태로 설정하는 것이 중요한데요.

이 부분에 대해서도 궁금증이 생겨서 알아본 결과를 공유할게요.

세션 관리: STATELESS의 의미

세션은 사용자가 로그인할 때 서버가 사용자 정보를 메모리에 저장하여 이후 요청마다 사용자 정보를 확인하는 방식입니다. 하지만 JWT를 사용할 때는 이러한 세션을 사용하지 않습니다.

대신 JWT는 사용자가 로그인할 때 서버가 사용자 정보를 포함한 토큰을 발급합니다. 이 토큰은 사용자가 이후 요청할 때마다 서버에 보내며, 서버는 토큰을 확인하여 사용자를 인증합니다. 이렇게 하면 서버는 상태를 유지할 필요가 없어 "STATELESS"라고 합니다.

• STATELESS: 서버가 사용자의 상태(로그인 상태 등)를 기억하지 않고, 모든 요청은 독립적으로 처리됩니다.
• JWT의 장점: 서버가 사용자 정보를 메모리에 저장할 필요가 없으므로 확장성이 뛰어나고, 서버 간 상태 공유가 필요 없습니다.

그래서 JWT를 사용할 때 폼 로그인, CSRF, HTTP Basic 인증을 비활성화하는 이유는 ???

JWT의 특성과 보안 요구 사항에 맞추기 위함입니다. 각각의 비활성화 이유를 설명하겠습니다.

1. 폼 로그인 비활성화

이유:

• JWT 기반 인증 방식: JWT를 사용할 때는 클라이언트가 사용자 인증 정보를 서버로 보내고, 서버는 이를 검증한 후 JWT를 생성하여 클라이언트에게 반환합니다. 클라이언트는 이후 모든 요청에 이 JWT를 포함하여 서버에 보냅니다. 이 방식은 전통적인 폼 로그인과 다릅니다.
• API 중심 접근: JWT는 주로 RESTful API와 함께 사용됩니다. RESTful API는 상태를 유지하지 않는 설계 원칙을 따르며, 클라이언트는 각 요청마다 인증 정보를 포함해야 합니다. 폼 로그인은 HTML 폼을 통한 인증에 적합하며, RESTful API와의 궁합이 좋지 않습니다.

2. CSRF 비활성화

이유:

• CSRF 방어의 필요성 감소: CSRF(Cross-Site Request Forgery)는 사용자가 의도하지 않은 요청을 공격자가 보내도록 하는 공격입니다. CSRF는 주로 서버가 세션을 사용하여 사용자를 인증하는 경우에 발생합니다. JWT를 사용하면 세션을 사용하지 않기 때문에, CSRF 공격의 주요 타겟이 사라집니다. 클라이언트는 요청마다 JWT를 포함해야 하며, JWT가 유효한지 검증하여 사용자를 인증합니다.
• CSRF 보호 내장: JWT는 자체적으로 CSRF 보호를 제공합니다. 클라이언트가 JWT를 보관하는 방식(예: HTTP 헤더)에 따라 CSRF 공격을 방어할 수 있습니다. 예를 들어, JWT를 Authorization 헤더에 포함하여 전송하면 CSRF 공격이 불가능해집니다.

3. HTTP Basic 인증 비활성화

이유:

• 보안 취약점: HTTP Basic 인증은 사용자명과 비밀번호를 Base64로 인코딩하여 전송합니다. 이는 인코딩일 뿐 암호화가 아니므로, 네트워크에서 쉽게 도청될 수 있습니다. HTTPS를 사용하지 않으면 매우 위험합니다.
• 상태 관리: HTTP Basic 인증은 상태를 유지하지 않지만, JWT는 보다 안전하고 유연한 인증 메커니즘을 제공합니다. JWT는 클라이언트가 토큰을 관리하고, 서버는 각 요청마다 토큰을 검증하기 때문에 더 안전합니다.
• 추가 기능: JWT는 사용자 정보를 토큰 내에 포함할 수 있어, 클라이언트가 추가 요청 없이 사용자 정보를 확인할 수 있습니다. HTTP Basic 인증은 이러한 기능을 제공하지 않습니다.

요약

• 폼 로그인 비활성화: JWT는 RESTful API와 함께 사용되며, 클라이언트가 각 요청마다 JWT를 포함하여 서버에 보내는 방식으로 작동합니다. 전통적인 폼 로그인이 필요하지 않습니다.
• CSRF 비활성화: JWT는 세션을 사용하지 않기 때문에 CSRF 공격의 주요 타겟이 사라집니다. 또한, JWT를 HTTP 헤더에 포함하여 전송하면 CSRF 공격을 방어할 수 있습니다.
• HTTP Basic 인증 비활성화: JWT는 HTTP Basic 인증보다 안전하고, 상태를 유지하지 않는 방식으로 인증을 처리하며, 추가적인 사용자 정보를 제공할 수 있는 기능을 갖추고 있습니다.