왜 세션 대신 JWT인가?
프로젝트 초기, 로그인 방식을 두고 세션과 JWT 중 고민을 했었는데 결론적으로 JWT 방식을 선택했다. 가장 큰 이유는 서버 리소스 효율성 때문이었다. 우리 프로젝트는 EC2 하나로 구동되기 때문에 세션 방식을 사용한다면 동시 접속자가 늘어날 수록 서버 메모리에 부하가 갈 수 있다고 판단했다. 따라서 상태를 서버에 저장하지 않는 JWT 방식이 우리 환경에 더 적합하다고 생각했다.
토큰 저장소의 분리
JWT의 약점은 탈취되었을 때 대처가 어렵다는 점이다. 이를 보완하기 위해 Access Token과 Refresh Token으로 분리하고, 저장 위치를 다르게 가져갔다.
Access Token : 클라이언트에서 화면 렌더링을 위해 토큰안에 userId같은 값을 추출해서 사용하기 때문에 javascript로 접근이 가능한 LocalStorage에 저장했고
Refresh Token : javascript로 접근할 수 없도록 HttpOnly 쿠키에 저장했다, 이를 통해 XSS 공격을 막고자 했다.
로그인 인증
백엔드에서는 로그인 요청이 들어오면 보안 검증과 토큰 발급이 이루어진다.
우선 비밀번호 검증은 단순 대조가 아닌 Spring Security의 AuthenticationManager에게 검증을 위임했다.
Refresh Token Rotation (RTR) 도입
단순히 토큰을 발급하는 것에서 그치지 않고, 토큰 탈취 시나리오를 대비해 RTR(Refresh Token Rotation) 전략을 적용했다. RTR이란, 사용자가 액세스 토큰 만료로 재발급(refresh)을 요청할 때, 리프레시 토큰까지 함께 폐기하고 새로 발급해주는 방식이다.
- 구현: refresh 요청 시 DB에 저장된 기존 리프레시 토큰을 새로운 토큰으로 덮어씌운다.
- 효과: 만약 해커가 리프레시 토큰을 탈취했더라도, 사용자가 한 번이라도 재발급을 받으면 해커가 가진 토큰은 즉시 무효화된다. (일회용 토큰 효과)
3. 확실한 로그아웃 처리
JWT는 서버에 세션이 남지 않아 로그아웃 구현이 까다롭지만, 보안을 위해 서버 측 개입이 필요하다고 판단했다. 따라서 로그아웃 요청 시 DB에 저장된 리프레시 토큰을 삭제하여, 더 이상 해당 계정으로 토큰 재발급이 불가능하도록 차단했다.
마무리
이번 로그인 구현을 통해 "편의성과 보안성 사이의 균형"을 배웠다. 서버 자원을 아끼기 위해 JWT를 선택했지만, 그로 인해 발생할 수 있는 보안 취약점(토큰 탈취)을 HttpOnly Cookie 저장과 Token Rotation 전략으로 보완했다. 단순히 "로그인이 된다"를 넘어, "안전하게 로그인된다"를 보장하는 백엔드 로직을 설계했다는 점에서 의미 있는 작업이었다.
'Project > Shift(현대이지웰 풀스택 과정)' 카테고리의 다른 글
| 회원탈퇴 - Soft Delete (0) | 2025.12.26 |
|---|