JWT 디코더 소개
이 무료 JWT 디코더는 JSON Web Token을 읽어 헤더와 페이로드를 서식이 적용된 JSON으로 보여주며, 발급 시각과 만료 시각은 읽기 쉬운 날짜로 변환해 줍니다.
디코딩은 브라우저 안에서 이루어지며, 토큰은 절대 업로드되지 않습니다. 사소한 얘기가 아닙니다. JWT는 대개 살아 있는 자격 증명이며, 이를 어딘가로 전송하는 웹사이트에 붙여 넣는 것은 그 토큰이 지닌 모든 접근 권한을 넘겨주는 일입니다.
이 도구는 토큰을 디코딩합니다. 서명은 검증하지 않습니다 — 그 구분이 왜 중요한지는 아래에서 설명합니다.
토큰의 세 부분
JWT는 점으로 구분된 세 개의 Base64url 덩어리입니다.
xxxxx.yyyyy.zzzzz
헤더 — 어떤 알고리즘으로 토큰이 서명되었는지, 그리고 어떤 유형인지를 나타냅니다. 보통 alg와 typ 두 필드입니다.
페이로드 — 클레임입니다. 토큰이 누구에 관한 것인지, 누가 발급했는지, 언제 만료되는지, 그 밖에 애플리케이션이 넣은 모든 것(사용자 ID, 이메일, 역할, 권한, 테넌트 등)이 들어갑니다.
서명 — 앞의 두 부분에 대한 암호학적 검사값으로, 비밀 키 또는 개인 키로 만들어집니다. 발급 이후 토큰이 변경되지 않았음을 증명합니다.
반드시 이해해야 할 핵심은 앞의 두 부분이 암호화되어 있지 않다는 점입니다. 단지 인코딩되어 있을 뿐이며 누구나 읽을 수 있습니다. 이 페이지에 토큰을 붙여 넣으면 내용이 즉시 나타납니다. Base64url은 데이터를 URL이나 헤더에 안전하게 담기 위한 방식이지, 숨기기 위한 방식이 아닙니다.
토큰에 무엇을 담을지에 대한 의미
페이로드는 토큰을 가진 누구에게나 공개되므로, 규칙은 곧바로 도출됩니다. JWT에는 절대 비밀 정보를 담지 마십시오.
페이로드에 들어가서는 안 되는 것: 비밀번호, API 키, 신용카드 정보, 주민등록번호 같은 국가 식별번호, 의료 정보, 개인정보 보호 규제의 대상이 되는 모든 것. 이 모두는 사용자 본인은 물론, 요청을 기록하는 모든 시스템과 토큰을 입수한 누구에게나 읽힙니다.
들어가도 되는 것: 사용자 ID, 역할, 만료 시각, 발급자, 대상자 — 토큰을 받는 시스템이 보도록 의도된 식별자와 클레임입니다.
서명은 무결성을 보호할 뿐 기밀성을 보호하지 않습니다. 아무도 토큰을 바꾸지 않았음을 보장하지만, 읽는 것을 막지는 못합니다.
디코딩은 검증이 아닙니다
이것이 실제 보안 결함을 일으키는 구분이므로 정확히 짚어 둘 가치가 있습니다.
디코딩은 Base64url을 풀어 JSON을 보여줍니다. 키가 필요 없고 누구나 할 수 있으며, 토큰이 진짜인지에 대해서는 아무것도 증명하지 못합니다.
검증은 비밀 키 또는 공개 키로 서명을 다시 계산해 일치하는지 확인합니다. 토큰이 정말로 주장하는 발급자에 의해 발급되었고 변조되지 않았음을 알려주는 것은 오직 이것뿐입니다.
토큰이 완벽하게 디코딩되면서도 완전한 위조일 수 있습니다. 누구나 "role": "admin"이라고 적힌 JWT를 만들 수 있고, 그것은 여기서 아주 보기 좋게 표시됩니다 — 표시하는 것이 전부이기 때문입니다.
이 도구는 의도적으로 검증하지 않으며, 그것이 안전한 선택입니다. 검증에는 서명용 비밀 키가 필요한데, 서명용 비밀 키를 웹 페이지에 붙여 넣는 일은 토큰을 붙여 넣는 것보다 훨씬 위험합니다. 검증은 본인의 서버에서, 본인의 키로, 제대로 된 라이브러리를 사용해 수행해야 합니다.
이 실수의 역사적 사례가 alg: none 공격입니다. 초기 JWT 라이브러리들은 알고리즘을 쓰지 않았다고 주장하는 헤더를 그대로 받아들여 토큰을 검증 없이 통과시켰습니다. 공격자는 페이로드를 수정하고 alg를 none으로 설정해 그대로 들어올 수 있었습니다. 현대 라이브러리는 이를 거부하지만, 헤더의 말을 믿지 말고 기대하는 알고리즘을 항상 고정해 두어야 하는 이유가 바로 여기에 있습니다.
표준 클레임 읽기
페이로드의 짧은 필드 이름 대부분은 의미가 정해진 등록 클레임입니다.
- exp — 만료 시각. 이후에는 토큰을 거부해야 합니다.
- iat — issued at, 발급 시각. 언제 생성되었는지.
- nbf — not before. 이 시각 전까지 토큰은 유효하지 않습니다.
- sub — 주체. 보통 사용자 ID입니다.
- iss — 발급자. 토큰을 만든 주체입니다.
- aud — 대상자. 어떤 서비스를 위한 것인지 나타냅니다.
- jti — 토큰 ID. 폐기 목록에 사용됩니다.
exp, iat, nbf는 Unix 타임스탬프, 즉 1970년 1월 1일 이후의 초 수입니다. 그래서 의미 없는 열 자리 숫자처럼 보입니다. 이 도구는 이를 읽기 쉬운 날짜로 바꿔 주는데, 여기까지 오게 만든 질문인 *이 토큰이 만료되었는가?* 에 답하는 가장 빠른 방법인 경우가 많습니다.
사용 방법
- JWT를 붙여 넣습니다(xxxxx.yyyyy.zzzzz 문자열)
- 아래에서 디코딩된 헤더와 페이로드를 확인합니다
- 필요하면 어느 쪽이든 복사합니다
알아두면 좋은 점
- 토큰은 비밀번호처럼 다루십시오. 아직 유효하다면 그것을 가진 사람은 누구나 해당 사용자로 행동할 수 있습니다. 살아 있는 토큰을 업로드하는 도구에 붙여 넣지 말고, 티켓이나 채팅에 올리지도 마십시오.
- JWT는 폐기하기 어렵습니다. 만료될 때까지 유효하므로, 차단 목록을 운영하지 않는 한 탈취된 토큰은 그때까지 작동합니다. 짧은 만료 시간이 중요한 이유입니다.
- Bearer 는 토큰의 일부가 아닙니다. 디코딩하기 전에 Authorization 헤더에서 이 접두사를 제거하십시오.
- Base64url은 표준 Base64가 아닙니다. +와 / 대신 -와 _를 쓰고 보통 = 패딩을 생략합니다. 그래서 JWT 조각이 일반 Base64 디코더에서 실패할 수 있습니다.
- 시계 오차는 혼란스러운 실패를 낳습니다. 본인에게는 유효해 보이는 토큰이 1~2분 차이 나는 시계를 가진 서버에서는 거부될 수 있습니다.
- JWT는 세션이 아닙니다. 클레임을 스스로 지니고 다니므로, 사용자의 역할을 바꿔도 토큰이 만료되기 전까지는 반영되지 않습니다.
자주 묻는 질문
JWT는 암호화되어 있나요?
아닙니다. 헤더와 페이로드는 Base64url로 인코딩되어 URL이나 HTTP 헤더에 안전하게 넣을 수 있지만, 내용을 숨기는 역할은 전혀 하지 않습니다. 이 페이지가 보여주듯, 토큰을 가진 사람은 그 안의 모든 클레임을 읽을 수 있습니다. 서명은 토큰이 수정되는 것을 막을 뿐, 읽히는 것을 막지는 않습니다.
이 도구가 서명을 검증하나요?
아닙니다. 의도적으로 하지 않습니다. 검증에는 서명용 비밀 키나 공개 키가 필요한데, 서명용 비밀 키를 웹 페이지에 붙여 넣는 일은 토큰을 붙여 넣는 것보다 훨씬 더 위험합니다. 검증은 제대로 된 라이브러리를 써서 본인의 서버에서 해야 합니다. 이 도구는 디코딩해 내용을 보여주며, 디버깅할 때 필요한 것이 바로 그것입니다.
여기에 제 토큰을 붙여 넣어도 안전한가요?
여기서는 안전합니다. 디코딩은 전적으로 브라우저 안에서 이루어지고 아무것도 전송되지 않으므로, 인터넷 연결을 끊어도 그대로 작동합니다. 다만 도구 일반에 대해서는 주의하십시오. 살아 있는 JWT는 실제로 작동하는 자격 증명이며, 이를 서버로 보내는 사이트는 그 토큰이 부여하는 모든 접근 권한을 넘겨받은 셈입니다.
토큰이 만료되었는지 어떻게 확인하나요?
초 단위 Unix 타임스탬프인 exp 클레임을 보십시오. 이 도구는 이를 읽기 쉬운 날짜로 바꾸고, 그 시점이 지났는지 직접 알려줍니다. 토큰이 유효해 보이는데 서버가 거부한다면 시계 오차를 확인하십시오. 기기 간 1~2분 차이면 충분히 발생합니다.
sub, iss, aud, iat은 무슨 뜻인가요?
모두 표준 의미를 지닌 등록 클레임입니다. sub는 주체로 보통 사용자 ID, iss는 토큰을 만든 발급자, aud는 의도된 대상자, 즉 어떤 서비스가 받아들여야 하는지를 뜻하며, iat은 발급된 시각입니다. exp, nbf와 함께 누가·어디서·언제를 모두 담습니다.
일반 Base64 디코더에서 JWT가 실패하는 이유는 무엇인가요?
JWT가 Base64url을 사용하기 때문입니다. +를 -로, /를 _로 바꾸고 보통 = 패딩을 제거하는 변형입니다. 이런 치환은 값이 URL 안에서 안전하도록 하기 위한 것입니다. 문자를 원래대로 되돌리면 표준 Base64 도구에서 디코딩됩니다.
JWT 페이로드를 수정할 수 있나요?
텍스트를 바꿀 수는 있지만, 그 결과는 올바르게 구현된 서버라면 모두 거부합니다. 서명이 수정된 내용과 더 이상 일치하지 않기 때문입니다. 서명은 정확히 그러라고 있는 것입니다. 토큰은 서명하는 서비스가 다시 발급하는 것이지, 손으로 고치는 것이 아닙니다.
관련 도구
- Base64 인코딩 / 디코딩 — 세 덩어리가 쓰인 인코딩 방식
- JSON 포매터 — 디코딩한 페이로드를 정리하고 살펴보기
- 해시 생성기 — 서명의 바탕이 되는 해시 함수
