Spring Security에서 보안 기능은 filter와 servlet의 도움으로 구현된다. 이번엔 servlet과 filter가 무엇이고 어떤 역할을 하는지 정리해보았다.
Servlet
우리가 백엔드 코드를 작성하고 이를 웹 서버에 배포하면, 클라이언트는 브라우저를 통해 우리가 작성한 API를 요청할 것이다.
이 요청은 HTTP/HTTPS 프로토콜로 전송되기 때문에 HTTP/HTTPS 프로토콜로 전송된 요청은 백엔드 서버/로직과는 무관할 것이다.
우리가 작성한 백엔드 코드는 Java이기 때문에, 모든 요청은 Java 객체로 변환되어야 백엔드에서 해당 요청을 처리할 수 있다.
이를 위해 Servlet Container가 사용된다. Servlet Container는 일종의 웹/앱 서버로, Spring Boot에서는 Tomcat이 Servlet Container의 역할을 한다.
우리가 작성한 백엔드 코드는 Web/App 서버로 배포될 것이고, Web/App 서버는 해당 서버가 받을 모든 HTTP request를 ServletRequest 또는 HTTP ServletRequest 객체로 변환한다.
ServletRequest, HTTP ServletRequest 객체에는 클라이언트가 보낸 데이터가 존재하게 되고 클라이언트가 보낸 요청이 ServletRequest 객체로 변환되면 이를 처리할 수 있는 해당 Servlet으로 전달된다.
요청이 Servlet으로 전달되면 이를 Spring framework가 활용한다. 우리가 작성한 Controller, Service에서의 비즈니스 로직은 이러한 servlet에서 호출된다.
백엔드 서버에서 클라이언트의 요청이 처리되면 해당 응답을 다시 클라이언트에게 보내야 하는데, 이 때 응답은 ServletResponse 객체의 형태로 전송된다. 여기서도 마찬가지로, 클라이언트 입장에서 SevletResponse 객체는 클라이언트와 무관하다. 따라서 응답을 보내는 경우에도 Servlet Container는 클라이언트에 응답을 전달하기 전에 ServletResponse 객체를 HTTP/HTTPS 프로토콜로 변환한다.
내부적으로 모든 비즈니스 로직은 Sevlet에 의해 처리되지만 Spring Boot 프레임워크가 내부적으로 Sevlet을 사용하여 처리하므로 우리는 비즈니스 로직에만 신경쓰면 된다.
Filter
클라이언트에서 요청을 보내고 해당 요청이 Servlet에 도달하기 전에 Filter를 거친다.
Filter는 클라이언트와 Servlet 또는 비즈니스 로직 사이를 오가는 모든 요청과 응답을 가로채는 역할을 한다.
Spring Security는 이러한 Filter를 활용하여 보안 관련 로직을 구현한다.
클라이언트가 API 요청, MVC 경로에 접근할 때 Spring Security는 해당 요청을 가로채고 사용자가 인증되었는지 등의 보안 기능 제공해야 한다.
Spring Security는 보안을 위해 클라이언트의 모든 요청을 가로채야 하므로 Spring Security의 모든 보안 로직은 Filter의 도움으로만 구현된다.
클라이언트로부터 요청이 올 때 Filter가 항상 먼저 실행되고, 이후에 Servlet이나 실제 비즈니스 로직이 실행된다는 점이 중요한 것 같다.
