JWT 만료와 not-before 타임스탬프 확인하기

문제 상황

JWT 인증 실패는 실제 원인이 nbf, issuer, audience, signature, revocation, server 정책인데도 만료 문제로만 요약되는 경우가 많습니다. RFC 7519 NumericDate는 Unix epoch부터의 초를 사용하지만 JavaScript API는 흔히 밀리초를 사용하므로 단위를 잘못 고르면 claim이 1970년 1월 근처나 의도와 전혀 다른 경계로 이동합니다. 원본 token에는 개인정보와 재사용 가능한 bearer credential도 들어 있을 수 있습니다. 제대로 검토하려면 필요한 숫자 claim만 초로 변환하고 verifier server의 UTC 평가 시각과 비교하며, 실제 system에 설정된 clock skew 허용치를 적용해야 합니다. 이 결과는 timing 증거일 뿐 token이 진짜이거나 권한이 있다는 증명이 아닙니다.

공식 출처와 표준

다음 공식 문서는 이 작업 흐름에서 다루는 형식과 보안 경계의 기준입니다. 도구별 실행 검증은 위에 별도로 기록합니다.

• RFC 7519: JSON Web Token (JWT)

  RFC Editor / IETF

• RFC 3339: Date and Time on the Internet: Timestamps

  RFC Editor / IETF

이럴 때 사용하세요

• API가 인증 또는 권한 오류를 반환했는데 client는 session이 아직 활성이라고 보고할 때
• decoded payload의 exp, nbf, iat를 원본 token 공유 없이 읽기 쉬운 UTC 경계로 바꿔야 할 때
• token 수명 경계 근처에서 browser, mobile, gateway, identity provider clock이 다를 때
• JavaScript 밀리초가 아닌 Unix 초로 문서화된 만료 구간이 있는 test fixture가 필요할 때
• 지원 메모에서 token timing과 signature, issuer, audience, scope, revocation 검사를 구분해야 할 때

단계

1. 1단계

   server 평가 시각 확보하기

   API gateway나 authorization server의 UTC 거부 시각, status code, request ID, 관련 policy version을 기록하세요. 사용자가 오류를 알아차린 시각보다 server가 평가한 시각이 더 직접적인 기준입니다.

2. 2단계

   승인된 로컬 환경에서만 decode하기

   검사 권한이 있는 token만 JWT Decoder에서 다루세요. 신뢰할 수 있는 로그에 필요한 claim이 이미 있으면 bearer token 자체를 취급하지 않는 편이 낫습니다. decoding은 signature를 검증하지 않습니다.

3. 3단계

   필요한 claim만 추출하고 비식별화하기

   exp, nbf, iat, iss, aud와 진단에 꼭 필요한 비민감 맥락만 남기세요. 공유 메모에서는 compact token, signature, session cookie, 불필요한 subject 식별자, 개인정보 claim을 제거하세요.

4. 4단계

   NumericDate를 초로 명시해 변환하기

   iat=1735686000, nbf=1735686000, exp=1735689600처럼 label이 있는 값을 붙여넣고 초를 선택하세요. NumericDate는 소수도 허용하지만 대부분 issuer는 정수 Unix 초를 만듭니다.

5. 5단계

   경계 규칙 적용하기

   요청은 exp 전에 평가되어야 하고 nbf 전에는 허용되면 안 되며 verifier의 문서화된 clock skew가 적용될 수 있습니다. 근사 상대 시간 문구가 아니라 정확한 숫자 시각을 비교하세요.

6. 6단계

   skew와 시간 외 거부 원인 확인하기

   허용 skew를 기록하고 server, client, issuer clock을 비교하세요. 이어서 signature 검증, algorithm policy, issuer, audience, token type, scope, revocation, session 상태를 독립적으로 점검하세요.

7. 7단계

   비식별화된 결론 작성하기

   변환된 UTC claim 경계, server 평가 시각, 적용한 skew, timing이 거부를 설명하는지 기록하세요. request ID와 policy 근거는 넣되 운영 원본 token을 티켓이나 스크린샷에 붙이지 마세요.

예시

iat=1735686000 nbf=1735686000 exp=1735689600
server_evaluated_at=2025-01-01T00:05:00Z
allowed_clock_skew=60초

iat: 2024-12-31T23:00:00.000Z
nbf: 2024-12-31T23:00:00.000Z
exp: 2025-01-01T00:00:00.000Z
server 평가: 2025-01-01T00:05:00.000Z
요청은 exp보다 300초 늦고 60초 skew 허용 범위 밖입니다. timing은 만료를 설명하지만 여기서는 signature와 권한을 평가하지 않았습니다.

흔한 실수

자주 묻는 질문