[설계의사결정] JWT + Redis 인증

AUTH

JWT + Redis 인증 설계 - 세션 대신 JWT를 선택한 이유

목차

• 1. 배경
• 2. 인증 방식 비교
• 3. 세션을 선택하지 않은 이유
• 4. 결정 — JWT + Redis
• 5. JWT의 한계

Booktine은 로그인 기반 기능이 많은 서비스다. 따라서 인증 구조를 어떻게 설계할지가 서비스 전체 구조에 큰 영향을 줬다.

1. 배경

Booktine은 로그인한 사용자만 이용할 수 있는 기능이 많다. 독서 기록 작성, 메모, 진행률 관리 등 대부분의 핵심 기능이 인증을 전제로 한다. 따라서 어떤 방식으로 인증을 처리할지가 중요한 설계 결정 중 하나였다.

 

핵심 기준은 다음과 같았다.

• 서버 확장성
• 프론트엔드(React)와의 연동 편의성
• 구현 복잡도

2. 인증 방식 비교

방식	설명	확장성	구현 난이도
세션	서버 메모리에 인증 정보를 저장하고, 클라이언트는 세션 ID만 갖는다.	낮음 (서버 상태 유지 필요)	낮음
JWT	인증 정보를 토큰에 담아 클라이언트가 직접 보관한다.	높음 (Stateless)	중간

세션은 서버 상태를 유지해야 하고, JWT는 Stateless 구조라는 차이가 가장 핵심이었다.

3. 세션을 선택하지 않은 이유

세션은 구현이 단순하고 Spring Security와의 기본 연동이 잘 되어 있다는 장점이 있다. 하지만 구조를 고려했을 때 몇 가지 문제가 있다고 판단했다.

• 서버 메모리에 세션 정보를 저장하기 때문에 서버 재시작 시 로그인 상태가 초기화된다.
• 서버를 수평 확장할 경우 세션 동기화 처리가 필요하다.
• React 기반 SPA와의 연동에서 CORS 설정이 복잡해질 수 있다.
• REST API 구조에서는 Stateless 방식이 더 자연스럽다.

무엇보다 프론트엔드가 React로 분리된 구조이기 때문에, 쿠키 기반 세션보다 토큰 기반 인증이 연동하기 더 편리하다고 판단했다.

4. 결정 - JWT + Redis

Access Token / Refresh Token 발급

JWT는 Access Token과 Refresh Token 두 가지를 발급하는 구조로 설계했다. Access Token은 만료 시간을 짧게 설정해 탈취 위험을 줄이고, 만료 시 Refresh Token으로 재발급받도록 했다.

JwtProvider에서는 Access Token과 Refresh Token 생성, Claim 파싱, 만료 검증 등의 핵심 JWT 로직을 담당한다.

JWT 내부 Claim 정보를 추출하고, 토큰 유효성 검사를 수행하는 로직이다.

 

Refresh Token을 Redis에 저장한 이유

JWT는 기본적으로 서버가 상태를 저장하지 않기 때문에, 한번 발급된 토큰을 서버에서 강제로 무효화하기 어렵다. 이 문제를 해결하기 위해 Refresh Token을 Redis에 저장했다.

• 로그아웃 시 Redis에서 Refresh Token을 삭제하면 재발급이 불가능해진다.
• Redis TTL 기능으로 만료 처리를 자동화할 수 있다.
• 메모리 기반 저장소라 조회 속도가 빠르다.
• RDB에 저장하는 방식보다 DB 부담이 적다.

별도 Repository 클래스 없이 StringRedisTemplate을 AuthService에서 직접 사용하는 방식으로 구현했다.

Refresh Token은 Redis에 TTL과 함께 저장된다. 이를 통해 만료 시간을 자동으로 관리할 수 있다.

로그인 유지 여부에 따라 Refresh Token의 TTL도 다르게 설정했다. 로그인 유지를 선택하지 않으면 최대 12시간으로 제한한다.

로그인 유지 여부에 따라 Refresh Token의 TTL을 다르게 설정해 보안성과 사용자 편의성 사이의 균형을 맞췄다.

로그인 및 토큰 발급 흐름
사용자가 로그인에 성공하면 서버는 Access Token과 Refresh Token을 생성한다. Refresh Token은 Redis에 TTL과 함께 저장되고, Access Token은 클라이언트에 전달된다.

 

로그아웃 및 Access Token 블랙리스트

로그아웃 시에는 Redis에서 Refresh Token을 삭제하고, 현재 Access Token을 블랙리스트에 등록한다.

Access Token은 만료 전까지 유효하기 때문에, 블랙리스트에 등록해 재사용을 막는다.

블랙리스트의 TTL은 Access Token의 남은 만료 시간으로 설정했다.

로그아웃 시 Refresh Token을 Redis에서 제거하고, 현재 Access Token을 블랙리스트에 등록한다.

로그아웃 및 토큰 무효화 흐름
로그아웃 요청이 들어오면 Refresh Token은 Redis에서 삭제된다. 동시에 현재 Access Token은 블랙리스트에 등록되어 만료 전까지 재사용되지 못하도록 차단된다.

JwtFilter에서는 매 요청마다 블랙리스트 등록 여부를 확인한다.

JwtFilter는 요청마다 Access Token이 블랙리스트에 등록됐는지 확인해 무효화된 토큰의 접근을 차단한다.

 

Access Token 재발급

Refresh Token 검증 후 Redis에 저장된 값과 일치하는 경우에만 새 Access Token을 발급한다.

Refresh Token 검증 후 Redis 저장값과 비교해 유효한 경우에만 Access Token을 재발급한다.

Access Token 재발급 흐름
클라이언트는 만료된 Access Token 대신 Refresh Token으로 재발급 요청을 보낸다. 서버는 Redis에 저장된 Refresh Token과 비교 검증 후 새로운 Access Token을 발급한다.

선택 이유

• React 기반 SPA와 토큰 기반 인증 연동이 자연스럽다.
• Stateless 구조로 서버 확장에 유리하다.
• Redis TTL로 Refresh Token 만료를 자동 처리할 수 있다.
• 로그아웃 시 Refresh Token 삭제 + Access Token 블랙리스트 등록으로 강제 무효화가 가능하다.

5. JWT의 한계

Access Token은 만료 전까지 서버에서 강제로 무효화할 수 없다. 따라서 탈취된 경우에도 만료 시간까지는 유효하게 사용될 수 있다는 단점이 있다.

 

다만 Access Token의 만료 시간을 짧게 설정하고, 로그아웃 시 블랙리스트에 등록하는 방식으로 이 문제를 최소화했다.

현재 Booktine 서비스 규모에서는 JWT + Redis 방식이 확장성과 구현 복잡도 사이에서 가장 적절한 균형이라고 판단했다.