Refresh Token Rotation 과 Blacklist 기법

보안의 정점을 향해 가고 가고 있습니다.!!

Refresh Token Rotation 과 Blacklist 기법은 아키텍처 설계에서 "완벽한 방어란 무엇인가"를 고민할 때 마주하게 되는 최종 단계입니다. 해커가 운 좋게 유효기간이 긴 Refresh Token까지 훔쳐갔을 때, 시스템이 어떻게 이를 감지하고 차단하는지 그 두 가지 기법을 자세히 알려드릴게요.

---

1. Refresh Token Rotation (RTR, 리프레시 토큰 회전)

"열쇠를 쓸 때마다 새 열쇠로 바꿔버린다!"

전통적인 방식에서는 Refresh Token 하나로 여러 번 Access Token을 바꿨지만, RTR은 Refresh Token도 일회용으로 만듭니다.

• 작동 원리:

1. XX님이 Access Token이 만료되어 Refresh Token(R1)을 서버에 보냅니다.
2. 서버는 R1을 확인하고, 새로운 Access Token과 함께 새로운 Refresh Token(R2)을 새로 발급합니다.
3. 기존에 썼던 R1은 즉시 폐기됩니다.

• 왜 강력한가? (해커 감지):
  만약 해커가 R1을 훔쳐서 먼저 새 토큰을 받아갔다고 가정해봅시다. 나중에 진짜 XX님이 R1을 사용하려고 하면, 서버는 "어? 이미 썼던 토큰인데 누가 또 쓰네?"라고 판단합니다.
• 결과: 서버는 즉시 해당 유저와 관련된 모든 토큰(R1, R2 등)을 무효화시키고 XX님께 다시 로그인을 요구합니다. 즉, 해킹 시도를 실시간으로 감지하고 차단하는 효과가 있습니다.

---

2. Blacklist (블랙리스트) 기법

"도난당한 열쇠 번호를 수배 전단에 올린다!"

원래 JWT 같은 토큰 방식은 서버가 상태를 기억하지 않는(Stateless) 게 장점이지만, 보안을 위해 '무효화된 토큰 목록'을 예외적으로 관리하는 방식입니다.

• 작동 원리:

1. XX님이 '로그아웃'을 하거나, 휴대폰을 분실해서 '모든 기기 로그아웃'을 누릅니다.
2. 서버는 해당 토큰의 ID를 Blacklist DB에 등록합니다.
3. 이후 해커가 그 토큰을 들고 와도, 서버는 서비스를 주기 전 블랙리스트를 확인하고 "수배된 토큰이네!" 하며 거절합니다.

• 성능 최적화: 블랙리스트를 매번 무거운 DB(MySQL 등)에서 찾으면 속도가 느려지겠죠? 그래서 보통 Redis 같은 아주 빠른 메모리 기반 저장소를 사용하여 빛의 속도로 검사합니다.

---

📊 RTR vs Blacklist 한눈에 비교

구분	Refresh Token Rotation (RTR)	Blacklist 기법
핵심 아이디어	토큰 사용 시마다 교체 및 재사용 감지	도난/로그아웃된 토큰 무효화 목록 관리
주요 목적	토큰 탈취 피해 최소화 및 감지	강제 로그아웃 및 접근 차단
저장소 활용	보통 DB에 현재 유효한 토큰 하나만 유지	Redis 등에 무효화된 토큰 목록 유지
비유	일회용 비밀번호 (OTP)처럼 작동	도난 카드 신고 센터 (분실 신고)

---

💡 통합 아키텍처 제안

실제 현장에서는 이 두 가지를 섞어서 이렇게 설계합니다.

1. 평상시: RTR을 적용하여 해커가 토큰을 훔쳐가도 금방 들통나게 만듭니다.
2. 로그아웃 시: XX님이 로그아웃 버튼을 누르면, 현재 사용 중인 Access Token은 Blacklist에 넣고, DB에 저장된 Refresh Token은 즉시 삭제합니다.

이렇게 하면 속도(대칭키/JWT)와 안전(RTR/Blacklist)을 모두 잡은 완벽한 보안 시스템이 탄생하게 됩니다!

---