🐤 JWT 기반 인증 도입 – 세션 방식 한계
기존 문제점
세션 방식은 서버가 상태를 기억해야 하므로 확장성과 유지비용 부담
Access Token만 사용할 경우 만료되면 무조건 재로그인 필요
모바일, SPA 환경 대응이 어려움
개선 내용
JWT Access + Refresh 구조 도입
Access Token은 1시간, Refresh Token은 7일 유지
클라이언트는 Access가 만료되면 Refresh로 토큰 재발급 요청 가능
효과
무상태(stateless) 인증 구현 가능 → 서버 확장 쉬움
사용자 경험(UX) 개선 → 자동 로그인 유지 가능
보안성 ↑: Refresh는 DB에 저장하고, 탈취 시 무효화 가능
🐤 Refresh Token 칼럼 추가 – 재발급 시 사용자 식별
기존 문제점
서버가 Refresh Token을 기억하지 않음
토큰 탈취나 재발급 시 클라이언트만 알고 있으면 위험
개선 내용
User 엔티티에 refreshToken 칼럼 추가
로그인 시 Refresh를 DB에 저장, 재발급 시 검증용으로 사용
효과
서버가 토큰 재발급을 제어할 수 있어 보안성↑
로그아웃 시 DB의 Refresh 제거 → 재발급 불가 처리 가능
🐤 로그인 시 Refresh Token 저장 – 무제한 재발급 방지
기존 문제점
클라이언트가 Refresh Token만 가지고 있으면 무한 재발급 가능
서버가 발급 여부를 제어할 수 없음
개선 내용
로그인 시 Access + Refresh 발급
Refresh는 사용자 DB에 저장
효과
서버가 발급 이력을 가지고 있어 통제 가능
탈취/유출 시에도 서버 측에서 무효화 처리 가능
🐤 Refresh Token 재발급 API 구현 – 자동 로그인 유지
기존 문제점
Access Token 만료 후 재로그인 필요
사용자 UX 불편
개선 내용
/api/auth/reissue API 구현
Refresh Token 유효성 검증 → Access + 새 Refresh 재발급
기존 Refresh는 DB에서 무효화 후 새로 저장
효과
사용자는 끊김 없이 자동 로그인 유지
기존 Refresh 탈취 방지 및 유효기간 제어 가능
🐤 UserRepository 확장 – Refresh Token으로 사용자 식별 가능하게
기존 문제점
JWT는 무상태 방식이라 사용자 ID 없이 토큰만으로 검증 어려움
재발급 시 사용자 매핑 불가
개선 내용
Optional findByRefreshToken(String refreshToken) 추가
효과
Refresh로 사용자 매핑 → 인증/재발급 제어 가능
DB 기반 인증 관리가 가능해져 보안성 향상
🐤 로그인 응답 DTO 도입 – 인증 응답 명확화
기존 문제점
로그인 응답을 단순 문자열로 처리
구조적 응답 부족 → 프론트에서 파싱 불편
개선 내용
public record LoginResponse(
String accessToken,
String refreshToken
) {}효과
명확한 응답 구조 → API 사용성 향상
추후 토큰 만료시간, 사용자 정보 확장 용이
