JWT 디코더 — 온라인으로 JSON Web Token 디코딩 _

JSON Web Token이란 무엇인가요?

JSON Web Token(JWT)은 작은 클레임 페이로드를 담기 위한 압축적이고 URL 안전한 봉투입니다. 상태가 없는 웹 세션, OAuth/OIDC ID 토큰, 머신 간 API 인증, 그리고 서명된 매직 링크의 표준 자격 증명 형식입니다. JWT는 항상 점으로 결합된 세 개의 base64url 세그먼트입니다: 헤더.페이로드.서명. 헤더와 페이로드는 JSON이며, 서명은 앞의 두 세그먼트에 대한 바이너리 MAC 또는 디지털 서명입니다.

JWT는 어떻게 작동하나요?

이 도구가 토큰을 디코드할 때는 모든 JWT 라이브러리가 따르는 동일한 세 단계 경로를 거칩니다:

1. 토큰을 점으로 나누어 정확히 비어 있지 않은 세 개의 세그먼트로 만듭니다. 그 외의 형태는 모두 잘못된 형식입니다.
2. 세그먼트 0과 1을 base64url 디코드한 다음 각각 JSON.parse로 파싱합니다. 헤더에는 알고리즘(alg)과 토큰 유형(typ)이 들어 있습니다. 페이로드에는 클레임(sub, exp, iat, 사용자 정의 키)이 들어 있습니다.
3. 비밀이 제공되면 헤더에 명시된 알고리즘으로 <세그먼트0>.<세그먼트1>에 대한 MAC를 다시 계산합니다. 결과 바이트를 세 번째 세그먼트와 비교합니다.
4. 검증 결과를 디코드된 클레임과 함께 표시하며, exp 클레임에서 계산한 사람이 읽기 쉬운 만료 표시도 함께 제공합니다.

브라우저에서 JWT를 디코딩하는 이유는 무엇인가요?

실제로 사용 중인 JWT를 원격 디버거에 붙여넣으면 해당 서비스의 로그, 관측 스택, 그리고 그 서비스가 데이터를 보내는 모든 파트너로 자격 증명이 유출됩니다. 제3자 사이트가 토큰을 로깅하지 않는다고 주장하더라도, 이를 검증할 방법은 없습니다. 이 도구는 그런 타협을 절대 하지 않아도 되도록 만들어졌습니다:

• 네트워크 없음: 런타임에는 fetch, XMLHttpRequest, sendBeacon 호출이 전혀 없습니다. 디코드하고 검증하는 동안 개발자 도구를 열어 보세요 — 네트워크 패널은 조용한 채로 있습니다.
• 네이티브 Web Crypto: HMAC 검증은 crypto.subtle.importKey와 crypto.subtle.sign을 사용하며, 이는 여러분의 런타임이 호출하는 것과 동일한 기본 요소입니다.
• 정적 배포: 모든 페이지는 침해할 서버 엔드포인트가 없는 단일 정적 HTML 파일입니다. 유출할 서버가 없으므로 유출될 토큰도 없습니다.

이 도구는 무엇을 검증하고 무엇을 검증하지 않나요?

이 도구의 버전 1은 HMAC-SHA 계열 서명만 검증합니다. 구체적으로:

• 지원: HS256, HS384, HS512. 공유 비밀을 제공하면 도구가 MAC를 다시 계산하여 비교합니다.
• 아직 지원되지 않음: RS256/384/512(RSA), ES256/384/512(ECDSA), EdDSA, PS256/384/512(RSA-PSS). 이들은 PEM 또는 JWK 형식의 공개키가 필요하며 후속 릴리스로 의도적으로 미루었습니다.
• 거부: alg: "none". 도구는 토큰을 디코드하지만 이를 안전하지 않다고 명시적으로 표시합니다 — 서명 검증이 전혀 이루어지지 않으며, 그런 토큰을 받아들이는 프로덕션 시스템은 심각한 취약점을 가지게 됩니다.

JWT 디코딩 예시는 어떻게 생겼나요?

위 입력 필드에 정식 RFC 7519 예시 토큰을 붙여넣어 보세요:

헤더는 {"alg":"HS256","typ":"JWT"}로, 페이로드는 {"sub":"1234567890","name":"John Doe","iat":1516239022}로 디코드됩니다. 검증 패널에 your-256-bit-secret을 입력하면 서명 검사가 유효로 반환됩니다. 비밀의 단 한 글자만 바꿔도 무효로 반환됩니다. 이 중 어느 것도 여러분의 브라우저를 벗어나지 않습니다.

이것은 프로덕션에서 토큰을 디버그해야 했을 때 있었으면 했던 JWT 디코더입니다: 프라이버시를 존중하고, 빠르며, 런타임이 사용하는 것과 동일한 기본 요소 위에 만들어졌습니다.