JWT LIFECYCLE
JWT 만료와 재발급
JWT는 header, payload, signature로 생겼다는 설명만으로 운영 인증을
설계할 수 없다. access token과 refresh token의 수명, 서명 검증 실패,
rotation, blacklist, 탈취 의심 시 폐기 전략을 함께 둬야 한다.
짧은 access
공개 payload는 최소화하고 만료 시간을 짧게 잡는다
→
refresh rotation
재발급 때 이전 토큰을 무효화해 재사용 공격을 탐지한다
→
폐기 기준
logout, blacklist, tokenVersion으로 강제 종료 경로를 둔다
01
토큰 발급
로그인 성공 후 짧은 access token과 더 긴 refresh token을 역할에
맞게 발급한다.
payload에는 공개 가능한 식별 정보만 둔다
02
요청 검증
Guard가 Authorization header를 읽고 서명, 만료, issuer, audience를
확인한다.
decode만 하는 것은 검증이 아니다
03
만료 분기
access 만료는 refresh 경로로 보내고 refresh 만료는 재로그인을
요구한다.
401과 재발급 실패 응답을 구분한다
04
회전 처리
refresh를 사용할 때 새 토큰으로 교체하고 이전 토큰 재사용을 탈취
신호로 본다.
reuse detect가 없으면 훔친 토큰이 오래 산다
05
강제 폐기
로그아웃, 비밀번호 변경, 관리자 차단 시 token version이나
blacklist로 기존 토큰을 막는다.
JWT는 발급 후 자동 회수가 어렵다
Signature
위변조 검증
알고리즘과 secret/public key가 서버 정책과 맞아야 한다.
payload 신뢰는 서명 검증 뒤에만 한다
Expiry
수명 제한
access는 짧게, refresh는 보호 저장소와 회전 정책으로
관리한다.
길어진 access는 탈취 피해 시간을 늘린다
Rotation
재발급 안전성
refresh 사용 시 이전 값을 무효화해 재사용 공격을
탐지한다.
동시 요청 경쟁 조건을 고려한다
Revocation
강제 로그아웃
blacklist, user tokenVersion, session table 중 운영에 맞는 폐기
기준을 둔다.
stateless와 즉시 폐기는 서로 긴장한다
토큰 확인
서명 오류
변조된 payload와 다른 secret으로 만든 토큰이 거부되는지
확인한다.
만료 경계
access 만료, refresh 만료, 서버 시간 차이를 각각
재현한다.
탈취 시나리오
이전 refresh token 재사용이 감지되고 모든 관련 토큰이
폐기되는지 본다.