jwt 2

[쇼핑몰 프로젝트] Spring JWT 재발급 로직에서 Interceptor 대신 Filter를 선택한 이유 (+Spring Cloud OpenFeign, Spring MVC)

0. 개요쇼핑몰 프로젝트를 혼자 다시 구현하면서, 이전에 구현하지 못했던 Refresh Token 기반의 재발급 로직과 블랙리스트 기능을 새롭게 추가했다. Access Token이 만료됐을 때, 쿠키에 담긴 Refresh Token을 활용해 Auth 서버가 Redis에서 해당 토큰의 존재 여부를 확인하고, 유효한 경우 Access Token을 자동으로 재발급하는 구조를 구현했다. 로그인 후 발급되는 Access/Refresh Token은 모두 HttpOnly 쿠키로 설정되며, 이후 모든 요청에 함께 전달된다. 이 점을 활용해, 로그인한 사용자의 요청을 서버에서 선처리하고, Refresh Token은 존재하지만 Access Token이 없거나 만료된 경우 Auth 서버로 재발급 요청을 보내도록 설계했다. ..

[쇼핑몰 프로젝트] 서버 다중화 환경에서 세션 기반 인증 문제 해결 – JWT 적용

0. 개요쇼핑몰 프로젝트는 MSA 방식으로 설계했고, 클라이언트의 모든 요청은 먼저 Nginx로 받아서 이를 프론트 서버로 로드 밸런싱한다.이 프론트 서버에서 사용자 인증을 진행하는데, Spring Security를 사용했다. 그런데 간헐적으로 인증이 안되는 현상이 문제가 발생했다. 1. 문제 원인 분석문제는 Spring Security의 인증방식에서 비롯됐다. 로그인 시, Spring Security의 동작 과정을 보면  (1) 사용자의 인증 요청: 로그인 (아이디 - username, 패스워드 - password) (2) UsernamePasswordAuthenticationFilter요청에 세션ID(JSESSIONID)가 없으면, 사용자는 인증되지 않은 상태로 간주되고, 요청에서 username과 ..