Spring Security 동작 원리, 프로세스 이해하기

1. Spring Security 개요

 

Spring Security는 위와 같이 인증부터 편의성 유틸리티, 웹 브라우저에서 악용 가능한 세션 고정, 클릭재킹, 크로스 사이트 요청 위조(CSRF) 등의 공격으로부터 보호하는 메커니즘까지 포괄적인 기능을 제공하며, 이러한 기능은 모듈을 추가하는 것만으로도 모두 사용할 수 있다.

 

Spring Security를 도입하면 인증,인가 기능을 표준화 하고 자동화할 수 있어 개발자가 보안 관련 코드를 직접 작성하지 않고도 높은 수준의 보안 기능을 쉽게 구현할 수 있다.  

 

 

 

 

 

 

 

 

 

 

 

 

 

2. Spring Security 주요 아키텍처

Spring 에서 클라이언트로부터의 모든 HTTP 요청은 Dispatcher Servlet이 가장 먼저 수신한다. 이는 수신한 HTTP 요청 정보를 기반으로 적절한 컨트롤러에 요청 처리를 위임하는 역할을 한다.

 

 

또한, 운영 환경에 따라 서버로 들어오는 모든 요청에 대해 공통적으로 적용해야 할 부가 작업이 있을 때는 DispatcherServlet 이전 단계에 위치한 Filter가 이를 처리하게 된다. 

 

 

Filter는 javax.servlet.Filter 인터페이스를 구현한 클래스로, HTTP 요청이 DispatcherServlet에 도달하기 전에 요청과 응답을 가로채고 부가 작업을 처리하는 역할을 수행한다. 위 그림을 보면, DispatcherServlet은 Java Spring 컨테이너의 가장 앞에 위치하지만, Spring Security Filter는 Java Spring 컨테이너 앞에 위치한다. 

 

 

따라서 Filter 단계에서 인증, 인가, 로깅 등을 수행하면 Java Spring 컨테이너에 도달하기 전에 보안 위협을 차단하여 시스템 안정성을 높일 수 있다. 

 

 

 

 

Spring Security는 아래와 같이 Filter를 타며 여러 보안 기능들을 수행하게 된다. 

 

앞서 말했듯이 Java Spring의 IoC 컨테이너와는 별개의 컨테이너이기 때문에 Java Spring에서 정의된 Bean을 주입받아 사용할 수 없다.

 

웹 컨테이너는 DelegatingFilterProxy 클래스를 사용해서 Spring IoC 컨테이너에 정의된 특정 Bean(SpringSecurityFilterChain)에게 위임함으로써, Java Spring의 DI와 관리 기능을 사용할 수 있게 한다. 이를 통해 웹 컨테이너에서 생성된 Filter가 직접 요청을 처리하는 대신 해당 Bean이 요청을 처리하게 된다.

 

 

이러한 흐름을 그림으로 표현하면 다음과 같이 표현할 수 있다.

 

 

 

 

1. 사용자가 자원 요청 

 

2. Servlet Container의 필터들이 처리를 하게되고 그 중 DelegatingFilterProxy가 요청을 받게 될 경우 자신이 요청받은 요청객체를 delegate request로 요청 위임을 한다.

 

3. 요청 객체는 특정한 필터(springSecurityFilterChain) 에서 받게 된다.

 

4. FilterChainProxy에서는 자신이 가진 각각의 필터들을 차례대로 수행하며 보안처리를 수행한다.

 

5. 보안처리가 완료되면 최종 자원에 요청을 전달하여 다음 로직이 수행된다.

 

 

 

 

 

 

 

 

 

3. 인증 객체 관리

Authentication 인증객체란? 

당신이 누구인지 증명하는 것 사용자의 인증 정보를 저장하는 토큰 개념으로 사용한다. 

 

인증 시 id와 password를 담고 인증 검증을 위해 전달되어 사용된다. 

 

인증 후 최종 인증 결과(user 객체, 권한 정보)를 담고 SecurityContext 에 저장되어 전역적으로 참조가 가능하다.

Authentication authentication = 
	SecurityContexHolder.getContext().getAuthentication();

 

 

 

Authentication 객체의 구조는 아래와 같다.

 

1. principal: 사용자 아이디 혹은 User객체를 저장 

2. credentials: 사용자 비밀번호 

3. authorities: 인증된 사용자의 권한 목록 

4. details: 인증 부가 정보 

5. Authenticated: 인증 여부(Bool)

 

 

1. 사용자가 로그인을 시도(username + password 입력 및 전달)

 

2. usernamePasswordAuthenticationFilter(인증필터)가 요청정보를 받아서 정보 추출을 하여 인증객체 (Authentication)을 생성한다.

 

3. AuthenticationManager가 인증객체를 가지고 인증처리를 수행한다. 

 

4. 인증 성공 후 Authentication 인증객체를 만들어서 내부의 Principal, Credentials, Authorities, Authenticated 들을 채워넣는다.

 

5. SecurityContextHolder객체 안의 SecurityContext에 저장한다. → 인증객체를 전역적으로 사용할 수 있게 된다.

 

 

사용자 별 Authentication 인증 객체는 어떻게 구분할 수 있을까??

SecurityContextHolder라는 전역 객체 안에 SecurityContext에 인증 객체를 저장하는데, 

 

이 SecurityContextHolder는 ThreadLocal에 저장되기 때문에 각기 다른 쓰레드별로 다른 SecurityContextHolder 인스턴스를 가지고 있어서 사용자 별로 각기 다른 인증 객체를 가질 수 있다.

 

 

 

 

 

 

 

 

 

4. 인증 저장소

SecurityContext

Authentication 객체가 저장되는 보관소로 필요 시 언제든지 Authentication 객체를 꺼내어 쓸 수 있도록 제공되는 클래스이다. 

 

ThreadLocal에 저장되어 아무 곳에서나 참조가 가능하도록 설계됐고, 다른 Thread로 부터 안전하다. 

 

 

 

SecurityContextHolder

SecurityContext 객체를 저장하고 감싸고 있는 wrapper 클래스 

SecurityContext객체를 바로 저장하는 것은 아니고, 저장 방식(3가지 MODE)에 따라 저장을 하고 있다.

 

 

• MODE_THREADLOCAL: 스레드당 SecurityContext객체를 할당. default 
• MODE_INHERITABLETHREADLOCAL: 메인 스레드와 자식 스레드에 관하여 동일한 SecurityContext를 유지 → Parent, Child thread에서 동일한 SecurityContext를 가진다. 
• MODE_GLOBAL: 응용 프로그램에서 단 하나의 SecurityContext를 저장한다. → Memory에서 단 하나의 SecurityContext를 가지고 참조한다.

 

 

 

 

 

 

 

 

 

 

 

 

5. 폼(Form) 기반 로그인

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
    http
        .formLogin(formLogin -> 
            formLogin
                .loginPage("/login") // 로그인 페이지 URL
                .loginProcessingUrl("/loginProc") // 로그인 처리 URL
                .usernameParameter("userId") // 사용자 이름 파라미터 이름
                .passwordParameter("userPw") // 비밀번호 파라미터 이름
                .defaultSuccessUrl("/main") // 로그인 성공 시 이동할 URL
                .failureHandler(customAuthenticationFailureHandler) // 로그인 실패 시 처리
                .permitAll() // 모든 사용자에게 "/login" 페이지에 대한 접근 허용
        );

    return http.build();
}

 

Spring Security가 사용할 로그인 페이지를 지정하고, loginProcessingUrl() 함수에 지정된 URL로 로그인 요청이 전송되면 Spring Security가 usernameParameter(), passwordParameter()에 설정된 파라미터 값을 사용하여 사용자 정보를 데이터베이스에서 조회하고 사용자 인증을 처리한다.

 

 

 

플로우

1. 로그인 요청이 들어오면 UsernamePasswordAuthenticationFilter는 HttpServletRequest 에서 사용자 이름과 비밀번호를 추출하여 UsernamePasswordAuthenticationToken 이라는 인증 토큰을 생성

2. 생성된 토큰은 AuthenticationManager에게 전달

3. AUthenticationManager는 전달받은 토큰을 AuthenticationProvicer에게 전달

4. UserDetailsService를 통해 로그인 요청자의 정보와 데이터베이스에 저장된 사용자 정보를 비교한 후, 사용자 정보가 있을 경우 이를 AuthenticationProvicer에게 반환

5. AuthenticationProvicer는 전달받은 사용자 정보에서 패스워드 정보를 추출하여, 패스워드 비교. 일치할 경우 인증 토큰을 생성하여 AuthenticationManager에게 반환

6. AuthenticationManager는 사용자 인증 객체를 SecurityContextHolder에 저장

7, 8. 결과 처리

 

 

 

 

 

 

 

 

 

 

 

6. JWT 기반 로그인

JWT 란?

JWT는 Header, Payload, Signature 3가지 부분으로 구성된다.

 

Header는 두가지 정보를 가지고 있다. 서명에 사용할 암호화 알고리즘 관련 정보와 토큰의 유형을 알리는 정보가 담겨 있다.

 

Payload는 Claims라는 정보들을 가지고 있다. 클레임은 사용자와 같은 엔티티들이나 추가 정보들의 상태를 뜻한다. 클레임에는 Registered, Public, Private 3가지가 있다.

 

• Registered 클레임은 미리 정의된 클레임 세트이다. JWT 발급자, 토큰 제목, 토큰 만료 시간, 토큰 활성 날짜, 토큰 발급 시간, JWT 고유 식별자 등, 다양한 정보가 포함되는 클레임이다.
• Public 클레임은 사용자가 정의할 수 있는 클레임이다.사용자가 직접 정의하기 때문에 이 클레임에서 충돌이 발생할 수도 있다. 따라서 Public 클레임의 이름은 보통 URI로 정의해야 한다.
• Private 클레임도 사용자가 정의할 수 있는 클레임이다. 통신 당사자 간의 정보를 공유하기 위해 만들어진 클레임으로 공개되어도 상관없는 '사용자를 특정할 수 있는' 정보를 담는다.

 

Signature는 토큰에 포함된 정보들이 통신 과정에서 변경되지 않았다는 것을 검증하는 부분이다. Signature는 Header와 Payload를 Base64-URL로 인코딩한 문자열들과 Secret Key를 포함해 HMAC SHA256 암호화 알고리즘으로 암호화한다. 

 

빨간색은 Header, 보락색은 Payload, 파란색은 Signature이다.

 

 

 

 

플로우 

JWT 토큰을 사용한 인증, 인가 프로세스는 대략적으로 아래와 같다.

 

 

 

위 프로세스에 해당하는 로직은 아래와 같이 구현된다. 세부적인 코드들은 생략했지만, 흐름을 파악하기엔 충분할 것이다. 

@RequiredArgsConstructor
@Component
public class JwtFilter extends OncePerRequestFilter {

    private final JwtProvier jwtProvider;
    private final CustomUserDetailsService customUserDetailsService;

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response,
        FilterChain filterChain) throws ServletException, IOException {

        String token = extractToken(request);

        if (token != null && jwtProvider.validateToken(token)) {
            setAuthentication(token);
        }

        filterChain.doFilter(request, response);
    }

    private String extractToken(HttpServletRequest request) {
        String authHeader = request.getHeader("Authorization");
        if (authHeader != null && authHeader.startsWith("Bearer ")) {
            return authHeader.substring(7);
        }
        return null;
    }

    private void setAuthentication(String token) {
        Long memberId = jwtProvider.getMemberId(token);
        UserDetails userDetails = customUserDetailsService.loadUserByUsername(memberId.toString());

        UsernamePasswordAuthenticationToken authentication =
            new UsernamePasswordAuthenticationToken(userDetails, null,
                userDetails.getAuthorities());

        SecurityContextHolder.getContext().setAuthentication(authentication);
    }
}

 

 

 

 

 

 

 

 

 

 

 

 

 

(참고) 현재 로그인한 회원 & RBAC 관리

로그인한 회원을 가져오는 3가지 방법

1. SecurityUtils 사용

public class SecurityUtils {

    public static LoginMember getLoginMember() {
        Authentication authentication = SecurityContextHolder.getContext().getAuthentication();
        if (authentication != null && authentication.getPrincipal() instanceof UserDetails) {
            LoginMember loginMember = (LoginMember) authentication.getPrincipal();
            return loginMember;
        }
        return null;
    }
}

 

 

 

2. @AuthenticationPrincipal 어노테이션 사용

public class UserController {
    @GetMapping("/current-user")
    public String getCurrentUser(@AuthenticationPrincipal LoginMember loginMember) {
        return userDetails.getUsername();
    }
}

 

 

 

3. ArgumentResolver 등록

@AuthenticationPrincipal 어노테이션은 너무 길다면 ArgumentResolver를 별도로 등록해서 사용해도 좋다. 

@Component
public class LoginMemberArgumentResolver implements HandlerMethodArgumentResolver {

    @Override
    public boolean supportsParameter(MethodParameter parameter) {
        return parameter.getParameterType().equals(LoginMember.class);
    }

    @Override
    public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer,
        NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception {
        return SecurityContextHolder.getContext().getAuthentication().getPrincipal();
    }
}

@Configuration
@RequiredArgsConstructor
public class WebConfig implements WebMvcConfigurer {

    private final LoginMemberArgumentResolver loginMemberArgumentResolver;

    @Override
    public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
        resolvers.add(loginMemberArgumentResolver);
    }
}

 

public class UserController {
    @GetMapping("/current-user")
    public String getCurrentUser(LoginMember loginMember) {
        return userDetails.getUsername();
    }
}

 

 

뭘 사용해도 상관없지만 난 개인적으로 3번이 가장 맘에 든다. 

 

 

 

 

 

 

RBAC을 관리하는 2가지 방법

1. http.authorizeHttpRequests()

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

        // ... //

        http.authorizeHttpRequests(authorize -> authorize
            .antMatchers("/admin/**").hasRole("ADMIN") // 관리자만 접근 가능
            .antMatchers("/manager/**").hasAnyRole("ADMIN", "MANAGER") // 관리자와 매니저 접근 가능
            .antMatchers("/user/**").hasRole("USER") // 사용자만 접근 가능
            .antMatchers("/public/**").permitAll() // 모든 사용자 접근 가능
            .anyRequest().authenticated() // 그 외 요청은 인증 필요
        );

        return http.build();
    }

 

 

 

 

2. 메서드 기반 RBAC 설정

@Service
public class UserService {

    @PreAuthorize("hasRole('ADMIN')") // ADMIN만 접근 가능
    public void adminOnlyMethod() {
        System.out.println("Admin only method");
    }

    @PreAuthorize("hasAnyRole('ADMIN', 'USER')")
    public void adminOrManagerMethod() {
        System.out.println("Admin or Manager method");
    }

    @PreAuthorize("hasRole('USER')") // USER만 접근 가능
    public void userOnlyMethod() {
        System.out.println("User only method");
    }
}

 

 

1번째 방법은 /* 를 사용해서 패턴으로 관리하게 되는데 휴먼 에러가 발생하기 쉽다. 또한 특정 엔드포인트를 보고 필요한 권한을 알아보기 위해선 SecurityConfig에 들어가 직접 찾아봐야 한다. 

 

그래서 나는 개인적으로 2번째 방법을 더 선호하고 아래와 같이 custom annotaion을 만들어 사용하고 있다.