JWT 디코더

디코딩됐다는 것이 진짜 토큰이라는 뜻은 아닙니다

JWT를 처음 다룰 때 가장 흔한 오해입니다. 이 도구가 헤더와 페이로드를 예쁘게 풀어 주는 것은 그 부분이 그냥 base64url로 적힌 JSON이기 때문입니다. 열쇠도, 검증도 필요 없습니다. 즉 토큰을 아무렇게나 만들어 붙여넣어도 화면에는 멀쩡하게 나옵니다.

진짜인지 가리는 일은 세 번째 조각인 서명이 합니다. 서명은 헤더와 페이로드를 비밀키(HS256) 또는 개인키(RS256)로 계산한 값이라, 검증하려면 그 키가 있어야 합니다. 키는 서버에만 있어야 하므로 브라우저 도구는 원리상 검증을 할 수 없고, 해서도 안 됩니다.

이 토큰을 남의 사이트에 붙여넣지 마세요

JWT는 대개 로그인한 사용자를 증명하는 자격증명입니다. 비밀번호와 실질적으로 같은 무게를 가집니다. 서버로 값을 보내는 온라인 디코더에 운영 토큰을 붙여넣는 것은 그 서비스 운영자에게 계정을 잠시 빌려주는 것과 다르지 않습니다. 만료 전까지는 그 토큰으로 API를 그대로 호출할 수 있기 때문입니다.

이 도구는 서버로 아무것도 보내지 않고, 같은 이유로 입력한 토큰을 브라우저 저장소에 저장하지도 않습니다(다른 도구는 편의를 위해 입력을 자동저장하지만 이 도구만 예외입니다). 그래도 습관은 지키는 편이 낫습니다.

• 운영 토큰 대신 개발용·테스트 계정 토큰으로 확인하는 것이 원칙입니다.
• 토큰을 사내 메신저나 이슈 트래커에 붙여 공유하는 것도 같은 위험입니다. 필요하면 페이로드만 캡처해 공유하세요.
• 실수로 노출됐다면 만료를 기다리지 말고 서버에서 해당 세션을 무효화하거나 서명키를 교체하는 것이 정석입니다.

exp·iat 시간 클레임에서 자주 겪는 일

exp·iat·nbf 는 초 단위 Unix 시각입니다. 밀리초가 아닙니다. 자바스크립트에서 exp: Date.now() 라고 적으면 값이 1000배가 되어 서기 5만 년대 만료 토큰이 되고, 서버는 사실상 영원히 만료되지 않는 토큰을 발급하게 됩니다. 시간 클레임 표의 "사람이 읽는 시간"에 말도 안 되는 연도가 찍히면 이 실수를 의심하세요.

반대로 1000으로 나누는 것을 빠뜨린 채 이미 지난 시각을 넣으면 발급하자마자 만료됩니다. 표의 "남은/경과 시간" 칸은 1초마다 다시 계산되므로, 방금 발급받은 토큰인데 이미 "지남"으로 나온다면 발급 코드부터 보면 됩니다.

• exp 가 없는 토큰은 배지에 "exp 없음 — 만료되지 않는 토큰"으로 표시됩니다. 액세스 토큰이라면 설계를 다시 봐야 합니다.
• nbf(유효 시작)가 미래면 아직 못 쓰는 토큰입니다. 발급 서버와 검증 서버의 시계가 몇 초만 어긋나도 "아직 유효하지 않음"이 나오므로, 서버 검증 시에는 보통 수십 초의 여유(clock skew)를 둡니다.
• 표에 KST 시각과 UTC 시각이 함께 나옵니다. 로그에 찍힌 시각과 비교할 때는 그 로그가 어느 기준인지부터 확인하세요. 한국 서비스에서 "9시간 차이"로 헤매는 경우가 대부분 여기서 나옵니다.

alg=none 과 헤더를 믿으면 안 되는 이유

헤더의 alg 값이 none 이면 서명이 없는 토큰이라는 뜻이고, 이 도구는 노란 경고를 띄웁니다. 문제는 일부 라이브러리가 "헤더에 적힌 alg 대로 검증한다"고 구현했던 데 있습니다. 공격자가 alg 를 none 으로 바꾸고 서명을 지운 토큰을 보내면, 검증할 것이 없으니 통과해 버립니다. 페이로드의 role 을 admin 으로 고치는 것은 그다음 일입니다.

같은 결의 문제로 alg 혼동 공격이 있습니다. 서버가 RS256(공개키로 검증)을 쓰는데 토큰의 alg 만 HS256으로 바꿔 보내면, 순진한 구현은 공개키를 HMAC 비밀키로 착각해 검증합니다. 공개키는 말 그대로 공개되어 있으므로 누구나 유효한 서명을 만들 수 있게 됩니다.

페이로드에 넣으면 안 되는 것

클레임 설명 표를 보면 이 토큰이 무엇을 담고 있는지 한눈에 들어옵니다. 그 목록을 보면서 스스로에게 물어야 할 질문은 하나입니다 — 이 값들이 전부 남에게 보여도 괜찮은가. 페이로드는 암호화가 아니라 인코딩일 뿐이라, 토큰을 가진 사람은 물론 브라우저 저장소를 들여다볼 수 있는 확장 프로그램도 전부 읽습니다.

• 주민등록번호·휴대폰 번호·주소 같은 개인정보 — 넣지 마세요. 필요하면 서버에서 sub(사용자 ID)로 조회하면 됩니다.
• 내부 시스템 구조가 드러나는 값 — 내부 DB의 순번 ID, 관리자 경로 등.
• 토큰을 키우는 권한 목록 — JWT는 매 요청 헤더에 실려 갑니다. 권한이 수십 개면 요청마다 그만큼 트래픽이 붙고, 일부 서버·프록시는 헤더 크기 상한(흔히 8KB)에 걸립니다.
• 자주 바뀌는 값 — 토큰은 발급 시점에 박제됩니다. 등급을 강등해도 기존 토큰이 만료될 때까지는 옛 등급으로 통과합니다. 이것이 액세스 토큰의 수명을 짧게 잡는 이유입니다.