Redis가 없으면 JWT는 만료(exp) 전까지는 서버가 강제로 끊기 어려운 흐름이 기본이 되고,

Redis가 있으면 Refresh Token 저장/회전, Access Token 즉시 로그아웃 같은 서버 주도 제어가 가능하다.

회전(rotation)이란?

*Refresh Token으로 재발급을 한 번 성공할 때마다, 기존 Refresh Token은 즉시 무효화하고 새로운 Refresh Token을 다시 발급해 교체하는 방식을 뜻한다.

Refresh Token을 1회용처럼 만들어, 탈취된 옛 Refresh Token이 재사용되는 순간을 탐지/차단*

동작 흐름 (가장 기본)

1. 로그인: Access Token + Refresh Token 발급
2. Access Token 만료 → 클라이언트가 Refresh Token으로 /refresh 요청
3. 서버 검증 성공 시: 새 Access Token 발급 + 새 Refresh Token 발급, 그리고 기존 Refresh Token 폐기
4. 이후에는 새 Refresh Token만 유효하고, 이전 Refresh Token이 다시 제출되면 거부

왜 Redis/DB가 사실상 필요해지나?

회젼을 하려면 서버가 “현재 유효한 Refresh Token이 무엇인지”를 알아야 하고, 이는 서버 어딘가에 상태로 저장되어야 한다.

때문에 Redis가 있으면 세션키 → 현재 Refresh Token 같은 형태로 저장하고, 재발급 시 기존 값을 교체하는 구현이 쉬워진다.

회전 구현은 필수인가?

브라우저 기반 앱은 일반적으로 클라이언트 비밀키를 안전하게 보관하기 어렵다.

*OAuth 2.0 보안 BCP(RFC 9700)는 public client의 
refresh token은 sender-constrained(DPoP/mTLS 같은 소유 증명)로 묶거나
refresh token rotation을 사용해야 한다고 명시한다.

OWASP OAuth 2.0 치트시트도 
“Refresh tokens are sender-constrained or use refresh token rotation”이라고
같은 방향의 권고를 적고 있다.*

아무튼 회전은 사실상 표준으로 자리 잡고 있는 것 같다.