First Read

가장 많이 틀리는 건 숫자가 아니라 해석 순서

exp

이 시각 이후에는 토큰을 거부해야 한다는 뜻입니다. 문제는 서버 시간, 프록시 시간, 사용자의 로컬 시간이 모두 다를 수 있다는 점입니다.

nbf

이 시각 이전에는 토큰을 아직 쓰면 안 된다는 의미입니다. 발급 직후 호출에서 바로 실패하는 상황은 이 값과 clock skew를 먼저 의심해야 합니다.

iat

언제 발급되었는지를 뜻하지만, 검증에 직접 쓰이지 않는 경우도 많습니다. 다만 디버깅할 때는 세 클레임을 같이 봐야 흐름이 맞습니다.

Common Failures

실제 장애에서 자주 보이는 패턴

초와 밀리초를 섞어 읽음

JWT는 보통 Unix 초 단위를 쓰는데, 프런트엔드 코드나 로그 뷰어가 밀리초로 착각하면 시간이 완전히 다르게 보입니다.

검증보다 디코딩만 함

내용을 읽을 수 있다고 해서 유효한 토큰은 아닙니다. 외부 issuer 환경이라면 JWKS 기반 서명 검증이 별도로 필요합니다.

환경 시간 차이를 무시함

애플리케이션 서버와 인증 서버의 시간이 몇 초만 달라도 경계 구간에서 실패가 반복될 수 있습니다. 운영 문서에 허용 clock skew 기준을 적어두는 편이 좋습니다.

Workflow

이 사이트에서 바로 같이 볼 페이지

  1. JWT 디코더에서 헤더와 페이로드를 먼저 확인합니다.
  2. 타임스탬프 변환기exp, nbf, iat를 사람이 읽는 시각으로 다시 봅니다.
  3. 응답 전체 흐름을 재현해야 하면 API 요청 테스트를 같이 열어 요청과 응답을 함께 봅니다.