JWT 설계시 비번 변경시 토큰 무효화 방법

비밀번호를 변경했을 때 기존 JWT를 **무효화(invalidate)**하는 것은 JWT의 구조상 자동으로 되지 않기 때문에, 다음과 같은 추가적인 서버 설계가 필요합니다.

---

✅ 핵심 원칙

**JWT는 기본적으로 stateless(상태 없음)**이기 때문에, 토큰을 발급한 이후에는 서버가 그 토큰을 직접 "무효화"하지 않습니다.

🧩 그래서 문제는?

• 사용자가 비밀번호를 바꿔도, 이전 JWT는 여전히 유효기간(exp) 내에서는 사용 가능합니다.
• 공격자가 JWT를 탈취해놨다면, 비밀번호 변경 후에도 API를 호출할 수 있음.

---

✅ 해결 방법: 비밀번호 변경 시 JWT 무효화 구현 전략

전략 설명 구현 난이도 장점/단점

1. tokenVersion 방식	JWT payload에 tokenVersion을 포함하고, DB의 사용자 정보에도 저장. 비번 변경 시 이 값을 증가시키면 기존 토큰은 무효화됨	⭐⭐⭐ (추천)	무상태 JWT 유지하면서도 무효화 가능
2. 블랙리스트	서버가 "만료 전 토큰"을 저장하고 무효화 목록을 관리	⭐⭐⭐⭐	토큰 관리 복잡도 증가, Redis 등 필요
3. JWT 자체를 짧게 + Refresh Token	JWT는 짧게 (~15분), Refresh Token으로 재발급. 비밀번호 변경 시 Refresh Token을 무효화	⭐⭐⭐⭐	많이 쓰는 전략, 백엔드 토큰 관리 필요
4. 로그인 강제 만료	사용자의 lastPasswordChangeAt을 저장하고 JWT 생성 시 이 값과 비교	⭐⭐⭐	간단하지만 정밀 제어는 어려움

---

🔧 예시 1: tokenVersion 방식 (GraphQL Auth에서도 많이 씀)

JWT payload

{
  "userId": 123,
  "tokenVersion": 3,
  "exp": 1717043200
}

사용자 DB

userId: 123
password: "$2b$10$...."
tokenVersion: 3

로그인 시

• JWT 생성할 때 DB의 tokenVersion 포함

비밀번호 변경 시

• DB의 tokenVersion을 +1 증가
• 이전 JWT는 더 낮은 tokenVersion을 가지므로 모든 API에서 reject

서버에서 검증 예시

if (decodedToken.tokenVersion !== userInDB.tokenVersion) {
  throw new Error("Token is invalidated due to password change.");
}

---

✅ 요약

• 비밀번호 변경 시 기존 JWT는 자동으로 무효화되지 않음
• 서버에서 별도로 설계해야 함
• 가장 유연한 방식은 tokenVersion이나 lastPasswordChangeAt 등을 활용한 토큰 무효화 검증