exp
이 시각 이후에는 토큰을 거부해야 한다는 뜻입니다. 문제는 서버 시간, 프록시 시간, 사용자의 로컬 시간이 모두 다를 수 있다는 점입니다.
🔒 브라우저 내부 처리
JWT의 exp, nbf, iat 클레임을 어떻게 읽어야 하는지와, clock skew 때문에 자주 생기는 장애 패턴을 정리했습니다.
A practical guide to reading JWT exp, nbf, and iat claims, including the incidents that come from clock skew and bad assumptions.
First Read
exp이 시각 이후에는 토큰을 거부해야 한다는 뜻입니다. 문제는 서버 시간, 프록시 시간, 사용자의 로컬 시간이 모두 다를 수 있다는 점입니다.
nbf이 시각 이전에는 토큰을 아직 쓰면 안 된다는 의미입니다. 발급 직후 호출에서 바로 실패하는 상황은 이 값과 clock skew를 먼저 의심해야 합니다.
iat언제 발급되었는지를 뜻하지만, 검증에 직접 쓰이지 않는 경우도 많습니다. 다만 디버깅할 때는 세 클레임을 같이 봐야 흐름이 맞습니다.
First Read
expThis marks when the token should stop being accepted. The problem is that server time, proxy time, and the operator's local view can all differ.
nbfThis marks when the token should start being accepted. Immediate failures right after issue time often point here first.
iatIt tracks issue time and is not always enforced directly, but it becomes useful when you compare all timing claims together.
Common Failures
JWT는 보통 Unix 초 단위를 쓰는데, 프런트엔드 코드나 로그 뷰어가 밀리초로 착각하면 시간이 완전히 다르게 보입니다.
내용을 읽을 수 있다고 해서 유효한 토큰은 아닙니다. 외부 issuer 환경이라면 JWKS 기반 서명 검증이 별도로 필요합니다.
애플리케이션 서버와 인증 서버의 시간이 몇 초만 달라도 경계 구간에서 실패가 반복될 수 있습니다. 운영 문서에 허용 clock skew 기준을 적어두는 편이 좋습니다.
Common Failures
JWTs usually use Unix seconds. When frontend code or logs treat them as milliseconds, the resulting timestamps look completely wrong.
Readable tokens are not automatically trustworthy. External issuer setups still need signature validation through JWKS or an equivalent check.
Even a small time difference between application and auth servers can create repeated boundary failures. Teams should document acceptable skew explicitly.
Workflow
exp, nbf, iat를 사람이 읽는 시각으로 다시 봅니다.Workflow
exp, nbf, and iat into human time.