JWT 디코더

JSON 웹 토큰 안에 무엇이 들어 있는지 확인하세요.

토큰을 붙여넣으면 디코딩됩니다.
헤더
페이로드



서명


이 도구는 토큰을 디코딩만 하며 서명은 검증하지 않습니다. 토큰은 이 브라우저 탭 안에만 머뭅니다.
브라우저에서 실행됩니다. 입력한 내용은 어디로도 전송되지 않습니다.
JWT 디코딩 방법
  1. Bearer 접두사가 있든 없든 토큰을 붙여넣으세요.
  2. 정렬된 JSON 형태로 헤더와 페이로드를 확인하세요.
  3. 클레임 표에서 발급자, 대상, 만료 시각을 확인하세요.
JWT의 세 부분
부분인코딩내용
헤더Base64url JSON서명 알고리즘(alg)과 토큰 유형(typ)
페이로드Base64url JSON클레임(토큰의 실제 데이터)
서명Base64url 바이트헤더와 페이로드가 변조되지 않았다는 증명
자주 쓰는 서명 알고리즘
alg 값종류참고
HS256대칭, 공유 비밀 키하나의 앱이 자체적으로 토큰을 발급하고 검증할 때 흔함
RS256비대칭, RSAOAuth처럼 다른 쪽에서 토큰을 검증해야 할 때 흔함
ES256비대칭, 타원 곡선같은 보안 수준에서 RSA보다 짧은 서명
none서명 없음검증하는 쪽은 이 알고리즘을 항상 거부해야 함
RFC 7519의 표준 클레임
  • exp, nbf, iat는 모두 NumericDate 값으로, 유닉스 에포크부터의 초 단위이며 밀리초가 아닙니다.
  • aud는 문자열 하나일 수도, 토큰이 여러 대상을 위한 것이라면 문자열 배열일 수도 있습니다.
  • jti는 토큰마다 고유해야 하며, 이 덕분에 특정 토큰 하나만 차단 목록에 올릴 수 있습니다.
  • 표준 클레임은 모두 선택 사항입니다. 토큰은 애플리케이션이 정의한 사용자 지정 클레임만 가질 수도 있습니다.
JWT 디코더 자주 묻는 질문
JWT의 세 부분은 무엇인가요?
헤더, 페이로드, 서명이며 각각 base64url로 인코딩되어 점으로 연결됩니다. 헤더는 서명 알고리즘을 나타내고, 페이로드에는 클레임이 담기며, 서명으로 서버는 토큰 발급자를 확인할 수 있습니다.
이 도구가 서명을 검증하나요?
아니요. 헤더와 페이로드를 디코딩할 뿐 서명은 확인하지 않습니다. 신뢰하기 전에 비밀 키나 공개 키로 서버에서 검증하세요. 붙여넣은 토큰은 브라우저 밖으로 나가지 않습니다.
JWT의 페이로드는 암호화되어 있나요?
일반적인 서명된 JWT에서는 아닙니다. 인코딩만 되어 있어 토큰을 가진 사람이라면 누구나 읽을 수 있으므로 비밀번호나 개인정보는 절대 넣지 말아야 합니다. 암호화된 토큰(JWE)은 5개 파트로 구성되며 키가 필요합니다.
exp, iat, nbf는 무엇을 뜻하나요?
모두 1970년 1월 1일(UTC)부터의 초로 표시되는 시각입니다. exp는 토큰 만료 시각, iat는 발급 시각, nbf는 그 전에는 받아들이면 안 되는 시각입니다.
토큰이 만료된 것으로 표시되는 이유는 무엇인가요?
exp 시각이 기기의 시계보다 이전이기 때문입니다. 액세스 토큰은 보통 5~60분만 유효하므로 새 토큰을 요청하고, 컴퓨터 시계가 올바르게 설정되어 있는지도 확인하세요.
RFC 7519는 무엇을 정의하나요?
JWT 형식 자체, 즉 점으로 연결된 3개의 base64url 파트와 iss, sub, exp, aud 같은 표준 클레임의 의미를 정의합니다. 특정 서명 알고리즘을 요구하지는 않습니다.
JWT를 만료 전에 취소할 수 있나요?
토큰 자체는 그저 서명된 데이터이므로 스스로 취소할 수 없습니다. 조기에 취소하려면 jti 클레임을 기준으로 한 차단 목록이나, 짧은 만료 시간과 별도의 리프레시 토큰 조합처럼 서버 측 지원이 필요합니다.
exp와 iat가 날짜가 아니라 큰 숫자로 표시되는 이유는 무엇인가요?
토큰 안에서는 NumericDate 값, 즉 유닉스 에포크(1970년 1월 1일 UTC)부터의 초 단위 정수로 저장되기 때문입니다. 이 페이지는 편의를 위해 원래 숫자 옆에 읽기 쉬운 날짜도 함께 보여줍니다.
관련 도구