JWT(JSON Web Token) 디코더 - 헤더와 페이로드를 즉시 분석

JSON Web Token(JWT)는 세 개의 점(.)으로 구분된 문자열로 구성됩니다. 형식은 항상 헤더.페이로드.서명입니다. 이 세 부분은 모두 Base64URL 인코딩되어 있어 사람이 직접 읽을 수 없지만, 디코딩하면 원래의 JSON 구조를 확인할 수 있습니다. 헤더에는 일반적으로 사용된 알고리즘(예: HS256, RS256)과 토큰 유형(typ)이 포함됩니다. 페이로드는 실제 데이터가 담긴 부분으로, 사용자 식별 정보나 권한, 만료 시간(exp) 등이 들어갑니다. 마지막 서명은 토큰의 무결성을 보장하기 위한 것으로, 비밀 키 또는 공개 키를 사용해 생성됩니다. JWT 디코더는 이 세 부분 중 헤더와 페이로드만 로컬에서 디코딩하여 보여주며, 서명은 검증하지 않습니다. 이는 브라우저 내에서만 처리되므로 서버로 전송되지 않아 안전합니다. 예를 들어, eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...와 같은 토큰을 붙여넣으면, 헤더에 {"alg":"HS256","typ":"JWT"}와 같은 내용이 표시됩니다. Base64URL 디코딩 과정은 Base64 디코더와 유사하지만, JWT는 패딩(=)을 제거하고 URL 안전 문자만 사용한다는 점에서 다릅니다.

JWT 페이로드에는 다양한 클레임(claims)이 포함될 수 있으며, 그중 일부는 RFC 7519에서 정의된 표준 클레임입니다. 대표적인 것들로는 iss(issuer, 발급자), sub(subject, 주제), aud(audience, 대상), exp(expiration time, 만료 시간), iat(issued at, 발급 시각), nbf(not before, 이 시간 이전에는 사용 불가)가 있습니다. 이 값들은 모두 Unix 타임스탬프(초 단위)로 표현되며, JWT 디코더는 이를 자동으로 한국어 사용자에게 친숙한 날짜 형식(2024년 12월 12일 등)으로 변환해 표시합니다. 예를 들어, exp: 1735689600은 2025년 1월 1일 오전 9시(한국 표준시 기준)를 의미합니다. aud가 "my-mobile-app"이라면 이 토큰은 해당 앱에서만 유효하다는 뜻이며, 다른 서비스에서 사용하면 거부됩니다. 이러한 클레임을 이해하면 API 인증 오류를 더 정확히 진단할 수 있습니다. 특히 nbf와 iat는 서버 간 시계 차이(clock skew) 문제를 파악하는 데 유용합니다. 클레임 값은 JSON 형태로 보기 쉽게 정렬되어 표시되며, 필요 시 JSON 포맷터를 활용해 추가 가공도 가능합니다.

JWT 디코더는 토큰을 '읽을 수는 있지만 믿을 수는 없습니다'. 이 도구는 Base64URL 인코딩된 헤더와 페이로드를 해석해 사람이 읽기 쉬운 JSON으로 보여주지만, 서명(signature)을 검증하지 않습니다. 즉, 토큰이 조작되었는지, 실제로 신뢰할 수 있는 발급자로부터 온 것인지 판단하지 못합니다. 예를 들어, 누군가 페이로드의 exp 값을 임의로 늘려서 재인코딩한 가짜 토큰을 만들어도, JWT 디코더는 그 내용을 정상적으로 표시합니다. 하지만 실제 서버에서는 서명 검증 단계에서 이 토큰을 거부합니다. 따라서 디코딩은 디버깅이나 학습 목적으로만 사용해야 하며, 인증 로직에서 '디코딩된 내용 = 신뢰 가능한 데이터'라고 간주해서는 안 됩니다. 서명 검증은 반드시 서버 측에서 비밀 키 또는 공개 키를 사용해 수행해야 합니다. 이 도구는 모든 처리를 브라우저 내에서만 수행하므로, 토큰이 외부로 전송되지 않아 상대적으로 안전하지만, 민감한 프로덕션 토큰은 여전히 조심스럽게 다뤄야 합니다.

API 호출 시 "401 Unauthorized" 오류가 발생한다면, JWT 토큰 상태를 점검해보는 것이 첫 번째 단계입니다. JWT 디코더에 토큰을 붙여넣어 페이로드를 확인하면 흔한 문제 원인을 빠르게 파악할 수 있습니다. 가장 자주 발생하는 문제는 exp(만료 시간)가 현재 시간보다 이른 경우입니다. 예를 들어, 토큰의 exp가 2024년 6월 15일인데 오늘 날짜가 2024년 6월 16일이라면 이미 만료된 것입니다. 두 번째로 흔한 문제는 aud(대상)가 요청을 보내는 서비스와 일치하지 않는 경우입니다. 모바일 앱용 토큰을 웹 프론트엔드에서 사용하려고 하면 이런 오류가 발생합니다. 또한 nbf(사용 가능 시간)가 미래로 설정되어 있다면, 아직 토큰 사용이 허용되지 않은 상태입니다. 이는 서버와 클라이언트 간 시계가 맞지 않을 때 발생할 수 있습니다. 한국에서는 KST(UTC+9)를 기준으로 서버 시간을 맞추는 것이 일반적이므로, 개발 환경에서도 동일한 타임존을 사용하는지 확인하세요. 디코딩 결과에서 이러한 클레임 값을 확인한 후, 필요 시 Base64 인코더를 이용해 수정된 페이로드를 다시 인코딩해 테스트할 수도 있습니다.

Q: JWT를 디코딩하는 것과 검증하는 것은 같은가요? A: 아닙니다. 디코딩은 Base64URL을 해석해 내용을 읽는 것뿐이며, 토큰의 진위나 무결성은 확인하지 않습니다. 검증은 서명을 비밀 키로 재계산해 비교하는 별도의 과정이 필요합니다. Q: 토큰의 만료 시간을 어떻게 확인하나요? A: JWT 디코더에 토큰을 입력하면, exp 클레임이 자동으로 사람이 읽기 쉬운 날짜(2024년 12월 31일)로 변환되어 표시됩니다. Q: 프로덕션 환경의 토큰을 여기에 붙여넣어도 안전한가요? A: 이 도구는 모든 처리를 브라우저 내에서만 수행하며, 토큰을 서버로 전송하지 않습니다. 그러나 토큰 자체가 민감 정보(예: 사용자 ID, 권한)를 포함할 수 있으므로, 불필요하게 노출하는 것은 피하는 것이 좋습니다. Q: 토큰이 디코딩되지 않는 이유는 무엇인가요? A: JWT 형식이 아닐 수 있습니다. 정확히 세 부분(헤더.페이로드.서명)으로 구성되어야 하며, 각 부분은 유효한 Base64URL 문자열이어야 합니다. 일부 문자가 손상되었거나, URL에서 복사할 때 특수문자가 변형된 경우에도 실패할 수 있습니다.