DB를 거치지 않은 JWT을 통한 사용자 식별에 관해 (2025년 4월 7일)

 

2025년 4월 7일의 고민 노션에서 옮겨오고 있습니다.

 

고민

 

만약 토큰에 식별자만 넣으면 JWT필터에서 인증객체를 만들기 위해 DB를 조회해야하지 않나?

프론트에서는 페이지마다 /userinfo API로 서버에 유저정보를 요청할것이고 서버는 응답으로 유저정보를 반환한다. 그리고 필터는 모든 API요청마다 작동한다.

그럼 모든 요청마다 DB를 조회해야하나? 그럼 토큰을 사용하는 의미가 없다.

시큐리티컨텍스트홀더를 활용해서 최초한번만 DB를 조회하게하는 방법은 없나?

---

해결

 

1. 우선 필터에서 DB를 조회하면 안된다. 필터는 서버를 들어오는 요청을 사전에 확인하는 거름망으로 Tomcat 서버의 필터레벨에 스프링 시큐리티의 필터체인이 삽입된다. 스프링의 필터체인에는 JWT필터도 있고 아직 웹 서버에 도착하지 않은 상태의 필터단에서 DB에 접근하는 로직이 있는 것은 아키텍처의 일관성이 없어지고 보안상으로도 좋지 않다. JWT필터는 토큰의 위조 검사, 토큰의 유효성을 검사를 담당해야 한다.

 

2. 그럼 서버안에 도착해서 DB를 조회하더라도 매 요청마다 유저 정보를 반환하기 위해 DB를 조회해야하는 것 아닌가? 이것은 민감 정보와 그렇지 않은 정보를 구분해야 한다. 민감 정보는 유저가 특정 API를 실행할 때 DB를 조회하는 것이 맞다. 즉 토큰안에 포함되면 안되는 것. 하지만 매 페이지마다 쓰이는 민감하지 않은 정보 만약 유출된다해도 공격자가 그 정보만으로 얻을 것이 없는 것들은 토큰에 포함시켜도 된다.

즉, userId = 1 하나만 넣는 것 보다 유연하게 토큰의 구조를 짜서 보안과, 서버의 불 필요한 오버헤드 감소, 성능의 균형점을 찾는 것이 중요하다.

 

3. 아니면 최초 API 요청에만 DB를 조회하고 프론트의 세션 / 로컬 스토리지에 저장할 수도 있다. 그렇게 하면 그 후로 부터는 유저 정보 API를 호출할 필요가 없다. 다만 프론트의 스토리지에 저장하는 방식은 매번 유저정보를 서버에서 반환해주는 방법보다 보안상 좋지 않다. 첫 서비스임을 감안했을 때 유저의 보안 사고만은 절대적으로 예방해야하므로 성능을 조금 포기하더라도 보안을 더 중시하는 방향으로 가야겠다. 

 

4. 시큐리티 컨텍스트 홀더를 활용해여 최초 한번만 DB를 조회할 수는 없다. 시큐리티 컨텍스트 홀더는 사용자의 정보를 담아두는 일종의 메모리이고 stateless하다. 많은 사용자가 접근 할 때 시큐리티 컨텍스트 홀더가 특정 사용자 한명을 계속 추적할 수 없다. 때문에 매 요청 마다 필터를 통과할 때 추출한 사용자 정보를 시큐리티 컨텍스트에 담아야한다.