해시·ID·난수
JWT 내용과 만료 시각으로 무엇을 알 수 있나요?
사용할 도구
API가 401을 반환하면 만료를 의심하지만 JWT에 미래 시각이 적혔다고 서버 오류는 아닙니다. 서명·발급자·대상도 별도 검증 조건입니다. 실제 인증 정보를 예시나 문의에 붙이지 않고 가상 토큰으로 시각 읽기를 살펴봅니다.
점 두 개로 나뉜 세 부분
아래 값을 JWT 디코드에 넣으세요. 점 두 개가 Header·Payload·Signature를 나눕니다. alg none·빈 서명의 설명용 예시라 로그인에 쓸 수 없습니다. 도구는 Base64url JSON을 읽을 뿐 파싱 성공을 신뢰로 판단하지 않습니다.
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJkZW1vLXVzZXIiLCJpYXQiOjE3MDQwNjcyMDAsIm5iZiI6MTcwNDA2NzIwMCwiZXhwIjoxNzA0MDcwODAwfQ.실제 JWT에는 사용자 식별자·권한이 들어갈 수 있습니다. Base64url은 암호화가 아니라 서명된 Payload도 읽을 수 있습니다. 읽는 것과 바꾼 뒤 인증을 통과하는 것은 다르며, 후자에 관련된 서명 검증을 이 도구는 하지 않습니다.
exp·nbf·iat는 각각 어떤 시각인가
예시 iat·nbf는 1704067200, UTC 2024-01-01 00:00:00이고 exp는 한 시간 뒤 1704070800입니다. iat는 발급, nbf는 수락 시작 경계, exp는 만료입니다. 발급 시각이 있다고 항상 수명 한 시간은 아니며 이 예시만 그렇게 설정했습니다.
iat = nbf = 2024-01-01T00:00:00Z
exp = 2024-01-01T01:00:00ZNumericDate는 Unix 초 기준입니다. Date.now()의 밀리초를 exp에 그대로 넣으면 뜻이 달라집니다. 자릿수만 보고 고치지 말고 생성 측 단위를 확인해 Unix 변환에서 초로 읽으세요. 날짜 문자열과 숫자 Claim은 다르며 이 화면은 숫자 Claim의 시각을 해석합니다.
기기 시계와 검증 서버 시계는 별개
도구는 기기 현재 시각과 비교한 참고를 보여주며 exp와 같으면 만료 쪽입니다. 서버 시계·허용 오차·인증 라이브러리 설정은 알 수 없습니다. 기기 시계가 느리면 화면에서는 미래여도 서버에서는 지났을 수 있습니다.
현지에서 아직 오늘이라는 판단도 부족합니다. UTC 01:00과 일본 10:00은 같은 순간이고 표시 시간대를 바꿔도 수명이 늘지 않습니다. UTC·오프셋과 기기 관측인지 서버 로그인지 구분하세요. 이 도구는 서버 시계를 조회하지 않습니다.
만료 값을 바꿔도 인증은 고쳐지지 않음
exp를 미래로 바꿔 재인코딩하면 디코더에는 미래가 나오지만 서명 대상 내용이 바뀌어 원래 서명이 맞지 않습니다. 인증은 적절한 검증이 필요합니다. 디코드 성공·미래 시각을 인증 성공으로 오해하지 않도록 미검증 표시가 있습니다.
iss·aud가 보여도 실제 발급자·현재 API 대상임을 확인한 것은 아닙니다. alg도 입력이지 신뢰 설정이 아닙니다. 외부 키·인증 서버 조회가 없으므로 다음은 검증 측 설정·로그를 확인하며 전체 토큰 대신 필요한 식별 정보·시각만 공유하세요.
읽히지 않는 형식을 억지로 JWT로 바꾸지 않기
이 화면은 세 부분 JWT이며 다섯 부분 암호화 JWE·서비스 고유 불투명 토큰은 지원하지 않습니다. 오류가 없어질 때까지 구분자·문자를 지우면 원본 검사가 아닙니다. 복사 범위·따옴표·Authorization의 Bearer 접두사를 확인하고 토큰 본문만 다루세요.
마지막에는 exp의 UTC 시각·기기 시계와 관계·여기서 서명 미검증을 정리하세요. 없는 Claim의 기한을 지어내지 마세요. 자동 저장이 없어도 화면 공유·캡처·클립보드 노출은 별개이므로 가상 예시로 연습하고 실제 데이터는 조직 규칙을 따르세요.
Payload의 admin이 권한 증명은 아닙니다
Payload의 role이나 userId가 권위 있는 정보처럼 보여도 화면은 선언된 값을 읽을 뿐입니다. 발급자, 대상, 서명, 현재 권한을 확인하지 않습니다. 미래의 exp도 이런 검증을 대신하지 못합니다. 디코딩 값을 디버깅 단서로 쓰는 것과 접근 허용의 근거로 쓰는 것을 구분하세요.
실패한 요청이 실제로 쓴 토큰부터 확인하세요. 다른 화면에서 복사한 미래 exp 토큰으로 실패 요청의 만료를 부정할 수는 없습니다. 토큰과 클라이언트·서버 시각을 같은 사건에 맞춰야 합니다. 실제 자격 증명을 살펴볼 때는 화면 공유와 클립보드 노출도 주의하고 공개 버그 보고에는 정제된 예를 쓰세요.
이 장치 기준 exp가 지났음, nbf 전으로 보임, 세 부분으로 해석 불가처럼 확인한 사실만 보고하세요. 유효한 JWT라는 표현은 디코딩 이상의 검증을 암시합니다. 시간을 고쳐 Payload가 읽혀도 원래 서명된 토큰을 복구한 것이 아니며 인증에서 받아들인다는 뜻도 아닙니다.