JWT 디코더 (헤더, 페이로드, 서명, 만료)

JWT 붙여넣어 즉시 헤더와 페이로드를 JSON으로 디코딩. 표준 클레임(iat, exp, nbf) 인식하고 Unix 타임스탬프를 ISO 8601로 변환. 만료 또는 미유효 토큰 플래그.

JWT 토큰

완전히 브라우저에서 디코딩. 토큰이 네트워크 통과하지 않음.

헤더

{
  "alg": "HS256",
  "typ": "JWT"
}

페이로드

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1730000000,
  "exp": 4886000000
}

서명 존재: ✓
발급 시간 (iat): 2024-10-27T03:33:20.000Z
만료 시간 (exp): 2124-10-30T22:13:20.000Z

작동 방식

JWT가 어떻게 보임

JWT는 점으로 연결된 세 Base64url 인코딩 세그먼트: header.payload.signature. 각 세그먼트가 URL 안전 전송용 인코딩된 JSON 객체. 헤더는 서명 알고리즘 선언, 페이로드는 클레임(주체, 만료, 사용자 정의 데이터) 운반, 서명은 키 있으면 수신자가 무결성 검증 가능하게.

본 디코더는 처음 두 세그먼트만 읽음. 서명은 세 번째 세그먼트지만 검증은 비밀/공개 키 필요 — 별도 작업, 여기서 안 함.

알아둘 표준 클레임

iss (issuer): 토큰 생성자. iat (issued at): 시점, Unix 타임스탬프. exp (expiry): 유효성 종료 시점, Unix. nbf (not before): 존중되어야 할 최早 시간. sub (subject): 대표하는 엔티티, 종종 사용자 ID. aud (audience): 토큰 대상, 보통 서비스 URL.

모두 필수 아님; 최소 JWT는 종종 sub + iat + exp만. 사용자 정의 클레임은 다른 모든 것 — 페이로드의 표준 옆에.

디코딩 ≠ 검증

누구나 JWT 디코딩 가능 — 헤더와 페이로드는 단지 Base64 인코딩된 JSON. 그래서 '페이로드에 비밀 두지 말기': 효과적으로 공개.

검증은 비밀 키(HMAC) 또는 공개 키(RSA/ECDSA)에 대해 서명 확인 의미. 검증 없으면 페이로드 안 어떤 클레임도 신뢰 불가 — 공격자가 어떤 페이로드든 조작 가능.

디버깅 중 토큰 검사에 본 도구 사용. 프로덕션에서는 서버 JWT 라이브러리로 검증.

자주 묻는 질문

›여기서 서명 검증 가능?

아니오 — 검증에 비밀이나 공개 키 필요, 이는 신뢰 환경 떠나면 안 됨. 서버 JWT 라이브러리(Node에 jsonwebtoken, Python에 PyJWT 등) 사용.

›토큰이 전송되나요?

절대. 디코딩이 로컬 실행; 받을 서버 엔드포인트 없음.

›왜 본 토큰이 '유효하지 않음'?

흔한 원인: 복사 붙여넣기로 공백 추가/제거, 세 세그먼트 중 누락, 한 세그먼트가 잘못된 Base64url. 트림하고 재시도.

›Base64url vs Base64?

Base64url이 '+'를 '-'로, '/'를 '_'로 교체하고 '=' 패딩 제거해 인코딩된 문자열이 URL과 HTTP 헤더에 안전. JWT는 항상 Base64url 사용.

›왜 본 유니코드 페이로드가 깨진 텍스트?

표준인 UTF-8 디코딩. 페이로드가 다르게 인코딩되었으면 JSON.parse 실패. 대부분 JWT 발급자가 UTF-8 올바르게 인코딩.

›HS256 안전?

비밀이 충분히 길면(≥256 비트) 비밀 유지하면 네. 흔한 HS256 취약점은 약한 비밀과 alg='none' 토큰 수용. ≥32자 무작위 비밀 사용하고 'none' 명시적 거부.

›왜 RS256이 HS256보다 선호?

RS256(비대칭 RSA)이 검증용 공개 키 발행하면서 서명 키 비공개 유지. HS256(대칭 HMAC)이 모든 검증자와 비밀 공유 필요. 다중 서비스 아키텍처에 RS256이 더 안전.

›거대 토큰 디코딩 가능?

실용 한도 ~10 MB; 그 이상 브라우저 느려짐. JWT는 보통 4 KB 미만; 더 크면 클레임에 너무 많이 저장하는지 고려.