[Spring Security] 스프링 시큐리티 알아보기, 구조(Filter Chain) 및 인증 과정

 

🤔 스프링 시큐리티?

스프링 기반의 어플리케이션의 보안(인증과 인가)을 담당하는 프레임워크를 말합니다.

인증(Authentication)

로그인 과정처럼 사용자가 시스템에게 자신을 식별할 수 있는 자격증명(아이디, 비밀번호, 토큰 등)을 제공하고, 시스템이 이를 확인하는 과정을 말합니다.

인가(Authorization)

인증된 사용자가 어떤 리소스에 접근할 수 있는지 또는 어떤 동작을 수행할 수 있는지를 검증하는 것 즉, 접근 권한을 얻는 일을 말합니다.

 

다양한 보안 기능, 인증 방식, 제어 메커니즘을 지원하여 보다 경력한 보안을 구현할 수 있습니다.

개발자는 이러한 기능을 통해 보안 관련 로직을 작성하지 않아도 된다는 장점이 있습니다.

 

스프링 시큐리티를 사용하지 않았을 때에는 컨트롤러에서 직접 인증과 인가를 구현하거나 Interceptor를 통해 컨트롤러에 도착하기 전 인증과 인가작업을 수행할 수 있었습니다.

하지만 스프링 시큐리티는 스프링 MVC와 분리되어 사용자의 요청이 보내지면 DispatcherServlet에 도달하기 전에 필터 체인을 통해 인증과 인가작업을 수행합니다.

 

 

✔ 스프링 시큐리티 구조

🔎 1. 필터 체인(FilterChain)

 

 

사용자 요청시 서블릿 컨테이너는 하나의 필터 체인을 생성합니다.

필터에 의해 요청이 필터링되었을 때, HttpServletResponse를 만들어 서블릿 대신 사용자에게 응답할 수 있습니다.

반대로 필터링 되지않고 다음으로 전달되게 할 경우 HttpServletRequest나 HttpServletResponse의 내용을 변경하여 다음 필터나 서블릿에 전달할 수 있습니다.

 

 

🔎 2. DelegatingFilterProxy

 

 

스프링 시큐리티는 필터의 생명주기를 이용하여 인증과 권한 작업을 수행합니다.

하지만 필터의 생명주기 시점에 서블릿 컨테이너에서는 스프링 컨테이너에 등록된 빈을 인식할 수 없습니다.

 

그래서 스프링 시큐리티에서는 DelegatingFilterProxy라는 서블릿 필터 구현체를 제공합니다.

서블릿 매커니즘을 통해 서블릿의 필터로 등록될 수 있으며 스프링에 등록된 빈을 가져와 의존성을 주입할 수 있습니다.

이렇게 DelegatingFilterProxy는 서블릿 컨테이너의 생명주기와 스프링의 ApplicationContext사이를 연결하는 다리 역하을 하게 됩니다.

 

DelegatingFilterProxy에서는 서블릿 필터에서 받은 요청과 응답을 스프링 빈으로 등록된 필터로 전달합니다.

 

 

🔎 3. FilterChainProxy

 

 

DelegatingFilterProxy의 내부에는 FilterChainProxy가 있습니다.

FilterChainProxy는 DelegatingFilterProxy를 통해 받은 요청과 응답을 SecurityFilterChain에 전달하고 작업을 위임하는 역할을 합니다.

바로 SecurityFilterChain을 실행할 수 있지만, 중간에 FilterChainProxy를 둠으로써 서블릿을 지원하는 시작점 역할을 하기 위해서입니다.

만약 서블릿에서 문제가 발생한다면 FilterChainProxy의 문제라는 것을 바로 알 수 있습니다.

 

또한 SecurityFilterChain이 여러 개로 구성될 경우, DelegatingFilterProxy에는 FilterChainProxy하나만 두고 여러 개의 SecurityFilterChain 중 선택하여 작업을 위임할지 결정할 수 있습니다.

 

 

🔎 4. SecurityFilterChain

 

 

인증을 처리하는 여러 개의 SecurityFilter를 담는 필터 체인입니다.

FilterChainProxy를 통해 서블릿 필터와 연결되고, 어떤 SecurityFilter를 통해 인증을 수행할지 결정하는 역할을 합니다.

 

 

여러 개의 SecurityFilterChain을 구성하여 요청되는 URL에 따라 다른 SecurityFilterChain이 사용되도록 할 수 있습니다.

 

 

🔎 5. SecurityFilter

요청을 스프링 시큐리티 메커니즘에 따라 처리하는 필터입니다.

DelegatingFilterProxy와 FilterChainProxy가 서블릿과 스프링과의 연결을 담당했다면, SecurityFilter는 시큐리티의 핵심 기능을 수행하는 지점입니다.

 

SecurityFilter는 SecurityFilterChain API를 통해 FilterChainProxy에 삽입되고 스프링 빈으로 등록됩니다.

 

 

✔ 스프링 시큐리티 인증 과정

 

1. 사용자의 자격증명(아이디, 비밀번호)이 Form을 통해 요청됩니다.

 

2. 요청은 AuthenticationFilter를 거쳐 요청된 정보를 통해 인증되기 전 UsernamePasswordAuthenticationToken을 1차로 생성합니다.

 

3. AuthenticationManager는 등록된 AuthenticationProvider들을 조회하여 인증을 요구합니다.

 

4. 실제 DB에서 사용자 인증 정보를 가져오는 UserDetailsService에 사용자 정보를 넘겨줍니다.

 

5. 넘겨받은 사용자 정보를 통해 DB에서 찾은 사용자 정보를 UserDetails 객체로 만듭니다.

 

6. AuthenticationsProvider들은 UserDetails를 넘겨받고 사용자 정보를 비교합니다.

 public class MemberService implements UserDetailsService {
 
 	@Override
    public UserDetails loadUserByUsername(String email) throws UsernameNotFoundException {
        Member member = memberRepository.findByEmail(email);

        if( member == null ){
            throw new UsernameNotFoundException(email);
        }

        return new MemberDetails(member); // MemberDetails는 UserDetails의 구현체
    }
    
}

 

UserDetailsService는 로그인 페이지에서 입력한 아이디를 통해 loadUserByUsername메서드를 호출합니다.

loadUserByUsername은 DB에 있는 사용자 정보를 UserDetails 형태로 리턴합니다.

 

7. AuthenticationsProvider들은 리턴된 UserDetails와  입력받은 사용자 정보가 일치하면 사용자 정보를 담은 Authentication 객체를 반환합니다.

 

[인증 성공]

8. 인증에 성공하게 되면 AuthenticationManager는 반환받은 사용자 정보를 포함하여 인증된 후의 UsernamePasswordAuthenticationToken(Authentication)을 2차로 생성하고 AuthenticationFilter로 보냅니다.

 

9. Authentication객체를 SecurityContext에 저장합니다, 이는 1차 캐시의 역할을 수행하며 인증 이후 사용자가 다시 요청을 보내게 되면 SecurityContext객체 안에 Authentication이 있는지 확인합니다.

 

 

 

---

 

📚 Reference

https://dev-coco.tistory.com/174

https://www.boostcourse.org/web326/lecture/58997?isDesc=false

https://limdevbasic.tistory.com/19

https://docs.spring.io/spring-security/site/docs/5.4.2/reference/html5/#servlet-security-filters