JWT이 즉시 만료되는 이유: exp는 밀리초가 아니라 초 단위입니다.

발행일: 10:00, 만료일: 10:00 — 처음 사용 시 거부된 토큰과 문제가 되지 않은 서버 시계

첫 번째 요청에서 토큰이 거부되면 서버 왜곡이 의심되지만 시계를 변경하기 전에 원시 클레임을 검사하세요. 한 구성 요소가 밀리초 시계에서 `exp`을 생성하는 동안 다른 구성 요소가 NumericDate 초를 비교하는 경우 값은 3배 정도 다릅니다. 일반적인 동기화 조정으로는 이러한 차이를 설명할 수 없습니다.

전달자 토큰은 자격 증명이므로 일회용 또는 수정된 토큰을 사용합니다. ToolAcre의 JWT 디코더는 페이로드 데이터를 읽지만 의도적으로 서명을 확인하지 않습니다. 원래 테스트 픽스처와 의도된 수명을 보존한 후에만 숫자 시간 요청을 타임스탬프 변환기에 복사하십시오.

RFC 7519의 내용 — 1970-01-01T00:00:00Z 이후의 초 단위 숫자 날짜와 문자열이 아닌 숫자인 이유

인접한 게시된 JWT 기사에는 이미 중요한 계약이 명시되어 있습니다. `exp` NumericDate는 Unix 시대부터 초를 계산합니다. 표준 설명을 반복하면 여기에 가치가 추가되지 않습니다. 실질적인 질문은 각 생산자, 직렬 변환기, 검증자 및 테스트 픽스처가 동일한 규모를 준수하는지 여부입니다.

명시적인 경계 코드를 찾습니다. 발행 시 밀리초 시계를 초로 나누고, 검증할 때 초 비교를 표시합니다. 청구서는 산술에 사용되는 형식화된 날짜가 아닌 숫자로 유지되어야 합니다. 사람이 읽을 수 있는 UTC는 토큰의 권위 있는 표현이 아니라 진단 예측입니다.

발행자 및 검증자 테스트에서 이 계약을 0이 아닌 값으로 고정합니다. 에포크 0을 사용한 테스트에서는 양쪽이 1000으로 나누어졌는지 아니면 곱해졌는지 알 수 없습니다.

기존 JWT 문서는 NumericDate 초를 설정합니다. 이 문서에서는 해당 사실을 만료 디버깅에 적용합니다.

검증자가 유효한 초 주장을 밀리초로 해석하는 경우 날짜는 1970에 가까워지고 만료된 것으로 나타납니다. 발급자가 나중에 초로 해석되는 필드에 현재 밀리초 값을 기록하는 경우 만료는 의도한 수명을 훨씬 초과하거나 라이브러리가 지원하는 범위를 훨씬 벗어납니다. 나타나는 증상은 어느 쪽에서 스케일 오류가 발생했는지 식별합니다.

자릿수를 기준으로 두 가지 양식을 모두 허용하는 "수정"을 피하십시오. 이는 잘못된 토큰을 영구적인 대체 프로토콜로 바꾸고 발급자 회귀를 숨길 수 있습니다. 애플리케이션의 NumericDate 계약을 위반하는 값을 거부하고 생성을 수정하며 초와 밀리초를 구별하는 고정 장치를 추가합니다.

밀리초 단위의 실수로 인해 어느 쪽이 잘못되었는지에 따라 즉시 거부되거나 믿을 수 없을 정도로 원격 만료가 발생할 수 있습니다.

페이로드를 디코딩하여 프레임워크가 변환하기 전에 `exp`, `iat` 및 `nbf`를 원시 값으로 노출합니다. `exp − iat`을(를) 의도한 토큰 수명(초)과 비교하세요. `nbf`를 별도로 확인하세요. 토큰은 만료되지 않았지만 사용할 수는 없습니다. 합리적으로 보이는 시대로부터 진정성을 추론하지 마십시오.

ToolAcre의 디코더는 서명 확인이 거짓이라고 보고하므로 해당 출력은 인증이 아닌 디버깅에 속합니다. 수정된 페이로드에는 공격자가 선택한 만료일이 포함될 수 있습니다. 신뢰할 수 있는 응용 프로그램 검증자는 원래 압축 토큰에 대해 알고리즘, 키, 발급자, 대상 및 시간 정책을 계속 시행해야 합니다.

작업된 예: 1700003600의 exp — 이를 UTC 및 현지 시간으로 변환하고, iat와 비교하여 확인하고, 수명이 의도한 것인지 확인합니다.

`iat = 1,700,000,000` 및 `exp = 1,700,003,600`의 경우 빼기 결과는 3,600초 또는 1시간이 됩니다. 변환기는 만료를 명시적으로 초로 읽고 `2023-11-14T23:13:20.000Z`을 반환합니다. 발행 시간은 `2023-11-14T22:13:20.000Z`입니다.

해당 숫자는 이 문서의 진단 예에 고유합니다. 밀리초를 선택하면 1월 1970 판독값이 생성되는 경우 이는 잘못된 척도의 증거로 예상됩니다. 1시간 정책이 올바르게 구현되었다고 결론을 내리기 전에 검증자의 현재 시간도 초 단위로 표시되는지 확인합니다.

포맷하기 전에 1시간 차이가 계산되므로 모든 영역에서 1시간이 유지됩니다. 로컬 디스플레이는 다를 수 있지만 `exp − iat`는 그렇지 않습니다.

작업된 예: 명시적인 초를 사용하여 exp 1,700,003,600를 근처 iat와 비교합니다.

검증자는 적당한 클럭 차이를 수용하기 위해 시간 청구에 대해 작은 애플리케이션 정의 허용 오차를 허용할 수 있습니다. 이 저장소는 권장 시간(초)을 정의하지 않으므로 여기에는 보편적인 여유가 규정되어 있지 않습니다. 보안 정책 및 라이브러리 구성이 권한입니다.

허용 오차는 1000배에 비해 아주 작게 유지되어야 합니다. 잘못된 클레임이 통과될 때까지 이를 확장하면 만료 시행이 약화되고 발급자 버그가 그대로 유지됩니다. 먼저 시계 단위와 동기화를 정규화합니다. 그런 다음 제한된 허용이 애플리케이션의 위협 모델을 제공하는지 여부를 결정합니다.

공차가 구성된 경우 해당 경계 내부 및 외부의 값을 몇 초 안에 테스트합니다. 이는 날짜 또는 로케일 렌더링과 독립적으로 정책을 입증합니다.

허용 오차는 1,000 요소 불일치를 복구할 수 없습니다.

타임스탬프 변환은 토큰의 서명, 허용된 알고리즘, 키, 발급자 또는 대상을 확인할 수 없습니다. 완벽하게 형식화된 향후 `exp` 클레임도 위조된 토큰 안에 있을 수 있습니다. JWT 디코더는 이 경계에 대해 의도적으로 투명하며 신뢰할 수 있는 검증자와 쌍을 이루어야 합니다.

또한 캡처된 프로덕션 토큰이 취소되었는지 또는 세션 정책이 명목 만료를 재정의하는지 여부를 설정할 수 없습니다. 민감하지 않은 픽스처를 사용하여 값을 디버그합니다. 실제 사건에서 자격 증명 검사가 필요한 경우 일반 클립보드 워크플로보다는 승인된 환경 및 처리 절차를 사용하십시오.

디코딩은 일상적인 디버깅 중에 합성 또는 안전하게 수정된 픽스처에서만 발생해야 합니다. 라이브 전달자 자격 증명을 복사하면 타임스탬프 산술과 관련 없는 보안 문제가 발생합니다.

요약: exp는 13자리가 아닌 10자리입니다. 그리고 JWT 디코더와 Unix 타임스탬프 변환기가 동일한 탭에 위치하여 몇 초 안에 청구를 확인할 수 있는지 확인하세요.

모든 경계에서 JWT 시간 주장을 초로 처리하고 그 차이를 기간으로 테스트합니다. 타임스탬프 변환기는 개별 클레임을 UTC 및 로컬 컨텍스트로 변환합니다. JWT 디코더는 원시 번호를 노출합니다. 그들은 함께 신뢰를 주장하지 않고 타이밍을 설명합니다.

지속성 수정은 토큰이 작동할 때까지 단위를 전환하는 지원 런북이 아닌 발급 및 확인 코드에 속합니다. 명시적인 초를 보존하고 잘못된 척도를 거부하며 서명 확인을 별도의 필수 결정으로 유지합니다.

이러한 분리는 관찰 가능성도 향상시킵니다. 생성 로그는 토큰을 노출하지 않고 기간 정책을 보고할 수 있으며, 확인 측정항목은 만료, 조기 및 유효하지 않은 서명 결과를 구별할 수 있습니다.