JWT 디코더가 실제로 하는 일
JSON Web Token(JWT)은 무작위 문자의 길고 불투명한 문자열처럼 보이지만, 암호화되지도 않았고 비밀 암호도 아닙니다. 두 당사자 간에 구조화된 데이터를 전달하는 컴팩트하고 URL에 안전한 컨테이너입니다. 위의 디코더에 토큰을 붙여넣으면, 그 문자열을 분해하여 내부의 실제 JSON을 보여줍니다. 메타데이터, 클레임, 토큰의 대상, 만료 시간 등을 확인할 수 있습니다. 모든 작업은 브라우저 내에서 이루어집니다. 토큰은 업로드되거나, 기록되거나, 어디에도 전송되지 않아서, 검사 중인 것이 실제 세션 자격 증명일 때 특히 중요합니다.

세 부분, 두 점
올바른 형식의 JWT는 세 개의 Base64url 인코딩 문자열이 점으로 연결된 것입니다: header.payload.signature. 파서가 한 섹션이 끝나고 다음 섹션이 시작되는 위치를 알 수 있는 것이 바로 이 단일 점 문자이며, 잘못된 수의 점이 있는 토큰이 다른 것을 읽기도 전에 거부되는 이유입니다.
헤더는 토큰 자체를 설명하는 작은 JSON 객체입니다. 거의 항상 typ(유형, 보통 JWT)과 alg — HS256(SHA-256을 사용한 HMAC) 또는 RS256(SHA-256을 사용한 RSA) 같은 서명 알고리즘을 포함합니다. 헤더는 검증자에게 서명이 어떻게 생성되었는지 정확히 알려줍니다.
페이로드는 대부분의 사람들이 관심을 갖는 부분입니다. 이것은 클레임 — 사용자와 토큰에 대한 진술을 담고 있는 또 다른 JSON 객체입니다. 사양은 클레임을 등록된 것(표준, 예약된 이름), 공개적인 것, 그리고 비공개적인 것(자신의 앱을 위해 만든 사용자 정의 이름)으로 구분합니다. 페이로드를 디코딩하면 누가 로그인했는지, 어떤 역할을 가지는지, 세션이 언제 만료되는지 확인할 수 있습니다.
서명은 암호화 인감입니다. 헤더의 알고리즘과 비밀 또는 개인 키를 사용하여 인코딩된 헤더와 페이로드에 걸쳐 계산됩니다. 두 섹션 모두를 포함하기 때문에, 헤더나 페이로드에 — 단 한 문자라도 — 변경이 있으면 무효화됩니다.
가장 자주 보게 되는 클레임
등록된 클레임은 서로 다른 시스템이 상호 운용할 수 있도록 RFC 7519에서 정의한 짧은 세 글자 이름입니다. 다음은 거의 어디서나 볼 수 있는 것들입니다.
iss— 발급자(issuer): 토큰을 발행한 주체(인증 서버 또는 ID 공급자).sub— 주제(subject): 토큰이 대상으로 하는 주체, 보통 안정적인 사용자 ID.aud— 대상(audience): 토큰이 의도한 수신자. API는 자신이 아닌 대상의 토큰을 거부해야 합니다.exp— 만료 시간(expiration time): 이 이후에는 토큰을 수락하지 않아야 하는 Unix 타임스탬프.iat— 발급 시간(issued at): 토큰이 생성된 Unix 타임스탬프.
nbf(not before)와 jti(고유 토큰 ID)도 만날 수 있습니다. 타임스탬프는 UTC 기준 1970년 이후의 초이므로, 사람이 읽을 수 있는 날짜로 렌더링해주는 디코더는 토큰이 이미 만료되었는지 확인하기 위한 암산을 덜어줍니다.
디코딩은 검증이 아닙니다 — 이 부분이 사람들을 실수하게 합니다
이 구분은 JWT에 대해 이해해야 할 가장 중요한 사항입니다. 디코딩은 내용을 읽는 것을 의미합니다. 키가 필요 없으며, Base64url은 암호화가 아닌 인코딩이기 때문에 토큰을 가진 누구나 할 수 있습니다. 검증은 토큰이 진짜이고 변조되지 않았음을 증명하는 것을 의미합니다. 올바른 비밀 또는 공개 키로 서명을 재계산하고 일치하는지 확인합니다.
이 도구는 디코딩을 합니다. 토큰이 말하는 것을 보여주지, 토큰이 신뢰할 수 있는지를 보여주지 않습니다. 토큰이 위조되거나, 만료되거나, 재사용된 경우에도 완전히 깔끔한 JSON으로 디코딩될 수 있습니다. 디코딩된 클레임만을 기반으로 권한 부여 결정을 내리지 마세요. 프로덕션에서는 서버 측에서 서명을 검증하고, exp를 확인하고, iss와 aud가 예상한 것과 일치하는지 확인합니다. 이때는 검증된 라이브러리를 사용해야 하며, 직접 만든 문자열 비교는 절대 안 됩니다.

페이로드는 금고가 아닙니다
페이로드는 Base64url로만 인코딩되어 있으므로, 토큰을 가로챈 누구든 읽을 수 있습니다. 페이로드의 모든 것을 공개적인 것으로 취급하세요. JWT 클레임에 비밀번호, 전체 신용카드 번호, 비밀 키, 또는 민감한 개인 정보를 넣지 마세요. 여기서 한 번의 클릭으로 디코딩할 수 있다면, 복사본을 얻는 누구든 마찬가지입니다. 서명은 수정에 대해 보호하지, 읽기에 대해서는 보호하지 않습니다. 페이로드 내용을 실제로 숨겨야 한다면, 그것은 완전히 다른 사양인 JWE(암호화된 토큰)의 역할입니다.
개인 정보 보호 및 관련 도구
토큰을 검사하는 것은 민감한 행위이므로, 이 디코더는 완전히 클라이언트 측에서 실행됩니다. 파싱은 탭의 일반 JavaScript이며 사용자 기기를 벗어나지 않습니다. 서버 기반 도구에 세션 토큰을 붙여넣는 것은 제3자에게 실제 자격 증명을 건네는 것으로, 반드시 피해야 할 행위입니다. 기반이 되는 인코딩에 대해서는 Base64 도구를 참조하고, 더 많은 기기 내 유틸리티를 위해 나머지 개발자 도구를 살펴보세요.
자주 묻는 질문
JWT는 암호화되어 있나요?
아니요. 표준 JWT는 암호화가 아닌 Base64url 인코딩입니다. 토큰을 가진 누구나 헤더와 페이로드를 읽을 수 있습니다. 내용을 숨겨야 할 경우 JWE를 사용하세요.
이 도구는 서명을 검증하나요?
아니요. 헤더와 페이로드를 디코딩하여 표시할 뿐입니다. 서명을 검증하려면 발급자의 비밀 또는 공개 키가 필요하며, 서버에서 수행해야 합니다.
여기에 토큰을 붙여넣어도 안전한가요?
예. 디코딩은 로컬 JavaScript를 사용하여 브라우저 내에서만 실행됩니다. 토큰은 어떤 서버에도 업로드, 저장 또는 전송되지 않습니다.
iss, sub, aud, exp, iat는 무엇을 의미하나요?
등록된 클레임으로, 각각 발급자, 주제, 대상, 만료 시간, 발급 시간을 의미합니다. 시간 관련 세 가지는 초 단위의 Unix 타임스탬프를 사용합니다.
디코딩 후 표시된 클레임을 신뢰할 수 있나요?
단독으로는 안 됩니다. 디코딩된 클레임은 위조되거나 만료된 토큰에서도 올 수 있습니다. 클레임을 신뢰하기 전에 항상 서명을 검증하고 서버 측에서 만료를 확인하세요.
토큰이 점으로 구분된 세 부분으로 되어 있는 이유는 무엇인가요?
그것들은 헤더, 페이로드, 서명으로, 각각 Base64url로 인코딩되어 점으로 연결됩니다. 점은 파서에게 각 섹션의 시작과 끝 위치를 알려줍니다.
