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 재사용이 감지되고 모든 관련 토큰이 폐기되는지 본다.