개발과 일상

이번 프로젝트를 진행하면서, 스프링 시큐리티를 도입하기로 했다. 현재 서비스는 그래도 제법 덩치가 있어서 바로 도입이 어렵기 때문에, 작은 서비스에 먼저 적용해보자는 취지였다. 결론부터 이야기하면, 현재 서비스 구조는 스프링 시큐리티에 필요한 데이터 구조를 가지고 있지 않았다. 이 과정에서 겪은 일들과 필터체인에 JWT를 엮는 일까지가 이번 포스팅이 될 것 같다. 우선 스프링 시큐리티가 뭔지부터 정리해보자. 스프링 시큐리티란? 스프링 시큐리티 공식 사이트에선 아래와 같이 스프링 시큐리티를 소개하고 있다. Spring Security는 강력하고 사용자 정의가 가능한 인증 및 액세스 제어 프레임워크입니다. 이는 Spring 기반 애플리케이션 보안을 위한 사실상의 표준입니다. Spring Security는 J..

이전 글에선 JWT 검증 코드를 인터셉터에 적용해봤다. 이번 글에선 Filter에 적용해보자. 먼저 가볍게 Filter에 대해 짚고 넘어가보자. Filter는 Interceptor와 다르게 Dispatcher Servlet이 동작하기 이전에 위치한다. 그리고 별도의 필터에 대한 설정이 없으면 모든 요청에 대해서 반드시 한번 실행이 된다. 때문에 인터셉터보다는 더 범용적이고, 한번은 무조건 타야하는 보안, 인증/인가 작업이 주로 Filter에서 이뤄지게 된다. 흔히 알고 있는 스프링 시큐리티의 필터 체인들이 여기서 수행된다. Filter는 별도의 설정없이 Filter 인터페이스만 implements해도 요청이 들어올 때마다 실행되기 때문에 구현은 비교적 간단하다. 구현 여기서부터 등장할 jwt 관련 코드는..

이전 글에서 JWT가 무엇이고 어떤 데이터를 실어서 보낼 수 있나를 알아봤다. 그럼 이번 글부터는 어떻게 적용하면 될지 알아보자. 이번 글에서 소개할 방식은 interceptor에 적용하는 방식이다. interceptor는 스프링에서 제공하는 컨트롤러 이전에 위치하는 공통처리부 중 하나이다. 아래 그림을 확인하면 편하다. 공통처리부에 관한 글을 예전에 썼었는데, 이 때는 스프링 MVC를 쓰던 시절이라 필터와 인터셉터를 xml에서 제어를 하도록 구성되어 있었다. (왜 썼는지, 어떤 역할을 하는지 보다 이런게 있다라고 정리한 글이었다) 여기서 추가적으로 간단하게 짚고 넘어가면, Interceptor는 스프링 내부에서 Dispatcher Servlet 이후에 동작한다. 컨트롤러 앞단에 위치해 요청과 응답을 간..

오랜만에 글을 쓴다. 9월에도 다양한 작업을 했지만, 새 서비스 런칭을 준비하면서 인증관련 작업을 할 일이 생겼다. 세션을 써야할까 JWT를 써야할까 고민하다가, 앞으로의 확장성과 러닝커브 등의 이유로 JWT를 선택했다. (서비스가 언젠가 MSA로 확장될 가능성이 있었다.) JWT를 적용하기 위한 방법으로는 크게 두 가지가 있었다. 1. filter에 적용 2. interceptor에 적용 기존 서비스는 interceptor에 적용되어 있었고, 이번 서비스에서는 filter+스프링시큐리티를 적용해봤다. 각각의 방범의 장단점이 있는데, 이 부분들은 차차 정리하도록 하고 이번 글에선 JWT에 대해서 알아보려고 한다. 1. JWT란? JSON 웹 토큰 (JSON Web Token, JWT)은 선택적 서명 및 ..