JWT의 구조
JWT는 헤더.페이로드.서명 세 부분을 점으로 이은 문자열입니다. 헤더는 서명 알고리즘(alg)과 토큰 종류를, 페이로드는 사용자 ID·권한·만료 시각 같은 "클레임"을 JSON으로 담습니다. 두 부분은 각각 Base64url(표준 Base64에서 +/를 -_로 바꾸고 = 패딩을 뺀 형식)로 인코딩되어 있을 뿐 암호화된 것이 아니므로 누구나 풀어서 읽을 수 있습니다. 이 도구는 그 디코딩을 외부 라이브러리 없이 직접 구현했고, 토큰은 브라우저를 떠나지 않습니다. 마지막 서명 부분은 헤더와 페이로드를 발급 서버의 키로 서명한 값으로, 내용이 변조되지 않았음을 서버가 확인하는 데 씁니다.
시간 클레임 읽는 법
exp(만료), iat(발급), nbf(이 시각 전에는 무효)는 1970년 1월 1일 UTC부터 센 초 단위 숫자(Unix time)입니다. 밀리초가 아니므로 자바스크립트 Date에 넣을 때는 1000을 곱해야 합니다. 이 도구는 UTC+9 한국 표준시로 바꿔 표시하고 현재 시각과의 차이를 함께 보여 줍니다. 만료 판정은 사용자의 PC 시계를 기준으로 하므로 시계가 틀리면 결과도 어긋납니다. 서버는 보통 몇 초~몇 분의 여유(clock skew)를 두고 검사합니다.
보안 주의
페이로드를 읽을 수 있다는 것은 토큰에 비밀번호·주민번호 같은 민감 정보를 넣어서는 안 된다는 뜻입니다. 개발자 도구나 이 같은 디코더로 누구나 볼 수 있습니다. 반대로 "읽을 수 있다"와 "바꿀 수 있다"는 다릅니다. 페이로드를 고쳐도 서명이 맞지 않으면 서버가 거부합니다. 단, 헤더의 alg가 none이거나 서버가 알고리즘을 검증하지 않는 구현이면 변조가 통하는 취약점이 있었으므로, 서버 쪽에서는 허용 알고리즘을 고정해야 합니다. 이 페이지는 서명을 검증하지 않으며 검증에 필요한 비밀키를 받지도 않습니다. 비밀키를 요구하는 웹 도구에는 키를 넣지 마세요. 토큰 자체도 그 사람으로 행세할 수 있는 열쇠이므로 스크린샷·이슈 트래커·채팅에 그대로 붙이지 않는 것이 원칙입니다.
디코딩이 안 될 때
점으로 나뉜 부분이 5개면 JWE(암호화된 토큰)라 키 없이는 읽을 수 없습니다. 부분이 3개인데 디코딩 오류가 나면 복사 과정에서 줄바꿈이나 따옴표가 섞였거나, 토큰이 중간에서 잘린 경우가 대부분입니다. 앞의 Bearer 는 자동으로 떼어 냅니다. 페이로드가 JSON이 아닌 JWT(드물게 중첩 JWT)는 오류로 표시됩니다.
자주 묻는 질문
서명 검증은 왜 안 해 주나요?
검증에는 발급 서버의 비밀키(대칭) 또는 공개키(비대칭)가 필요합니다. 비밀키를 웹 페이지에 넣게 하는 것은 위험하고, 공개키 검증은 발급자별 JWKS 주소가 달라 범용 도구로 만들기 어렵습니다. 검증은 서버 라이브러리(jsonwebtoken, PyJWT, jjwt 등)에서 하세요.
만료됐다고 나오는데 로그인은 되어 있어요.
액세스 토큰이 만료되어도 리프레시 토큰으로 새 토큰을 자동 발급받는 구조가 흔합니다. 또는 PC 시계가 틀렸을 수 있습니다.
한글 이름이 깨져요.
이 도구는 UTF-8로 디코딩하므로 정상 토큰이면 한글이 올바르게 보입니다. 깨진다면 발급 측이 비표준 인코딩을 썼거나 토큰이 손상된 경우입니다.