[Spring Security] Spring security Architecture

NewFit을 개발하면서 spring security에 OAuth2.0 + JWT의 조합으로 인증/인가를 구현했다.

단순히 코드를 여기저기서 긁어와서 구현하기보다 원리정도는 알고서 한줄 한줄 신중히 짜고 싶다는 생각에 공식 문서를 읽게 됐다.

지난 5월쯤에 처음 읽었을 때는 filter가 뭔지도 잘 모르겠었는데, MVC 강의를 들으면서 filter가 어떤 순서로 등장하고 어떻게 동작하는지를 배우고 다시 읽으니 이제는 이해가 되는 것 같다.

사실 아래의 내용은 공식 문서를 읽고 정리한지 두 달 정도 지난 내용이지만, 노션 창고에 있는 글을 하나씩 티스토리에도 옮기고자 이렇게 복붙 비슷한 걸 하게되었다.

Security Architecture

스프링 MVC를 공부하면서 서블릿과 필터 구조에 대한 이해도가 높아졌다.

과거에 spring security에 대해 공부했을 때는 와닿지 않았던 부분들을 더 잘 이해할 수 있을 것 같아, 공식 문서를 기반으로 spring security의 작동 원리를 공부하려고 한다.

Security와 Filter에 대한 이해

스프링 시큐리티는 필터 기반의 기술이다.

아래의 그림은 일반적인 HTTP request가 컨트롤러(혹은 핸들러)에 도달하기 전에 거쳐가게 되는 FilterChain이다.

스프링은 필터의 implementation으로 DelegatingFilterProxy 를 제공한다.

DelegatingFilterProxy는 스프링의 ApplicationContext와 ServletContainer를 연결해준다.

ServletContainer 내의 필터들이 동작 중에 DelegatingFilterProxy 가 요청을 받으면 DelegatingFilterProxy는 이를 Bean에게 위임하는데, 이 Bean이 바로 FilterChainProxy 다.

FilterChainProxy 는 여러 SecurityFilterchain을 가지고 있고, URL 패턴에 따라 적절한 FilterChain에게 처리를 위임한다.

이때 URL 패턴이 일치하는 단 하나의 FilterChain만을 호출한다.

public class FilterChainProxy extends GenericFilterBean {
    private List<SecurityFilterChain> filterChains;
}

실제로 FilterChainProxy 는 SecurityFilterchain 을 List<>의 type으로 가지고 있다.

지금까지의 내용을 한 눈에 정리할 수 있는 그림이다.

Security Filters

SecurityFilterchain은 여러 filter를 가진다.

이 필터들은 인증, 인가 등을 위해 사용된다.

필터들은 정해진 순서에 따라 호출된다.

인증 전에 인가가 이루어질 수 없다는 점을 생각하면 필터들의 순서가 정해져 있어야 하는 이유를 쉽게 이해할 수 있다.

SecurityFilterchain 에 대해 중요한 것은 각각의 필터 체인이 고유한 특성을 가지며 개별적이라는 점이다.

실제로 어떤 SecurityFilterchain 은 0개의 security filter를 가질 수도 있다.