RevealTheme logo

JWT 디코더

JSON Web Token(JWT)을 즉시 디코딩합니다. 브라우저에서 실행되므로 토큰이 기기를 벗어나지 않으며, 따라서 프로덕션 비밀 값과 함께 안전하게 사용할 수 있습니다.

이 도구 사용 방법

  1. 1

    입력란에 JWT를 붙여넣습니다.

  2. 2

    디코딩을 클릭하면 헤더와 페이로드가 파싱되어 표시됩니다.

  3. 3

    알고리즘, 클레임(claim), 만료 시각, 발급자를 확인합니다.

JWT란 무엇이며 어떻게 작동하나요?

JSON Web Token(JWT, RFC 7519에 정의됨)은 사용자에 관한 일련의 클레임(claim)을 표현하는 간결하고 URL에 안전한 방식이며, 그러한 클레임이 변조되지 않았다는 암호학적 증명을 함께 제공합니다. JWT는 대부분의 최신 웹 스택에서 인증을 담당합니다. 로그인하면 서버는 사용자 ID와 권한을 담은 JWT를 생성하고, 비밀 키로 서명한 다음 반환합니다. 브라우저는 토큰을 저장하고(보통 localStorage나 쿠키에) 이후의 모든 요청에서 Authorization 헤더에 포함합니다. 서버는 매 요청마다 서명을 검증합니다. 서명이 유효하면 토큰의 클레임을 신뢰하고, 변조된 경우에는 서명이 깨지므로 요청을 거부합니다. JWT는 점으로 구분되며 Base64URL로 인코딩된 세 부분으로 이루어집니다. 헤더는 서명 알고리즘을 선언하고(HMAC-SHA256은 HS256, RSA는 RS256, ECDSA는 ES256, 서명되지 않은 토큰은 none이며 이는 위험하므로 거부해야 합니다), 페이로드(payload)는 실제 클레임을 담으며(주체를 나타내는 'sub', 만료를 나타내는 'exp', 발급 시각을 나타내는 'iat' 같은 표준 클레임과 애플리케이션이 정의하는 모든 사용자 정의 클레임), 서명은 헤더와 페이로드가 비밀 값을 가진 누군가에 의해 서명되었다는 증명입니다. 이 디코더는 공개 정보인 처음 두 부분을 드러냅니다. 서명은 키가 있어야만 검증할 수 있으며, 이것이 모든 JWT 디코더가 클레임을 검증 없이 표시하는 이유입니다.

일반적인 사용 사례

  • 클라이언트가 보내는 JWT를 디코딩하여 인증 문제를 디버깅하세요. 어떤 클레임을 담고 있는지, 누가 발급했는지, 언제 만료되는지 정확히 확인할 수 있습니다.

  • API 게이트웨이(AWS Cognito, Auth0, Okta)의 JWT를 검사하여 다운스트림 서비스의 클레임 구조를 파악하세요.

  • 사용자 정의 클레임(조직 ID, 역할, 기능 플래그)이 토큰 발급 코드에서 올바르게 설정되는지 확인하세요.

  • 갱신 전후의 토큰을 비교하여 만료가 연장되었는지 확인하세요.

  • 토큰의 알고리즘을 감사하세요. 프로덕션에서 RS256 또는 ES256이 사용되고 'none'은 절대 사용되지 않는지 확인하세요.

  • 서버 로그의 base64url 페이로드를 읽을 수 있는 클레임으로 변환하세요.

자주 묻는 질문

프로덕션 JWT와 함께 사용해도 안전한가요?
그렇습니다. 디코딩은 로컬 JavaScript를 통해 전적으로 브라우저에서 이루어집니다. 토큰은 결코 저희 서버에 도달하지 않으며 어떤 로그에도 나타나지 않습니다. 디코딩하는 동안 DevTools → 네트워크 탭을 열어 확인할 수 있습니다. 외부로 나가는 요청이 전혀 발생하지 않습니다. 다만, JWT는 자격 증명처럼 다루세요. 디코더가 어디에서 실행되든 상관없이 URL, 스크린샷, 공유 문서에 붙여넣지 마세요.
이 도구가 서명을 검증하나요?
아닙니다. 서명 검증에는 비밀 값(HS256의 경우) 또는 공개 키(RS256/ES256/PS256의 경우)가 필요합니다. JWT를 검증하기 위해 비밀 값을 입력하라고 요구하는 웹 도구는 보안상의 위험 신호입니다. 서명 키를 낯선 이에게 보내는 셈이기 때문입니다. 서명은 서버에서 또는 직접 관리하는 라이브러리(jose, jsonwebtoken)로 검증하세요.
JWT가 만료되면 어떻게 되나요?
만료는 디코딩을 막지 않습니다. 'exp' 클레임은 페이로드 안의 단순한 데이터 한 조각일 뿐입니다. 디코딩된 페이로드에서 'exp'를 찾으세요. 이는 Unix 타임스탬프(1970년 이후의 초)입니다. 저희의 타임스탬프 변환기로 변환하면 사용자의 시간대에 맞춘 만료 시각을 볼 수 있습니다. 'exp'가 이미 지났다면, 디코더는 여전히 읽을 수 있더라도 규격을 준수하는 모든 검증기는 토큰을 거부합니다.
JWT를 암호화할 수 있나요?
그렇습니다. 그것을 JWE(JSON Web Encryption, RFC 7516)라고 합니다. 이 도구는 페이로드가 서명되어 있지만 볼 수 있는 일반적인 경우인 JWS(JSON Web Signature)를 다룹니다. JWE 토큰은 3개가 아니라 점으로 구분된 5개 부분으로 이루어지며 복호화하려면 수신자의 개인 키가 필요합니다. 토큰이 5개 부분으로 되어 있다면 JWE를 지원하는 도구가 필요합니다.
'alg': 'none'은 무엇을 의미하며 위험한가요?
'none'은 서명이 없다는 뜻입니다. 토큰이 서명되지 않았으므로 누구든지 어떤 클레임이든 위조할 수 있습니다. 프로덕션 시스템은 'alg: none' 토큰을 명시적으로 거부해야 합니다. 일부 라이브러리는 기본적으로 이를 허용합니다(잘 알려진 CVE 부류입니다). 항상 애플리케이션이 기대하는 알고리즘만 허용하세요.
세션 쿠키 대신 JWT를 사용하는 이유는 무엇인가요?
JWT는 무상태(stateless)입니다. 서버가 세션을 조회할 필요 없이 토큰 자체가 사용자의 신원과 권한을 담고 있습니다. 이 때문에 JWT는 분산 시스템과 API에 이상적입니다. 세션 쿠키는 상태를 가지며(서버에 세션 저장소가 필요함) 무효화하기는 더 쉽습니다(세션을 삭제하기만 하면 됩니다). 절충점은 이렇습니다. JWT는 확장성이 더 좋지만, 토큰이 만료될 때까지는 '사용자를 로그아웃'시킬 수 없습니다.
JWT의 표준 클레임에는 무엇이 있나요?
RFC 7519는 다음을 정의합니다. iss(발급자), sub(주체, 보통 사용자 ID), aud(대상), exp(만료 시각), nbf(이 시각 이전에는 무효), iat(발급 시각), jti(JWT ID). 이 외에 애플리케이션은 'roles', 'permissions', 'tenant_id' 같은 사용자 정의 클레임을 추가합니다. 사용자 정의 클레임은 작게 유지하세요. JWT는 모든 요청의 헤더에 실려 전송되므로 대역폭 사용량을 늘립니다.

관련 도구