본문으로 건너뛰기
yutils
JWT 디코더
예시

입력 (Payload + Secret + 알고리즘)

Payload:
{ "sub": "123", "name": "Alice", "exp": 1815000000 }

Secret: your-256-bit-secret
Algorithm: HS256

출력 (서명된 JWT)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiQWxpY2UiLCJleHAiOjE4MTUwMDAwMDB9.q3w...

참고

Web Crypto API 의 HMAC-SHA 사용. 같은 입력이면 항상 같은 토큰 — 결정적. secret 만 안전하게 보관하면 외부에서 위조 불가능.

사용법 / 자주 묻는 질문

이런 경우 사용하세요

  • API 인증 토큰 빠르게 발급 (테스트·로컬 환경)
  • JWT Decoder 로 디버깅하다 동일 secret 으로 재서명
  • 백엔드 라이브러리 없이 단일 토큰 빠르게 발급
  • exp · sub · role 같은 claim 직접 설정해 권한 테스트
  • HS256 ↔ HS384 ↔ HS512 알고리즘별 결과 비교

자주 묻는 질문

Q.RS256(공개키·비공개키)도 지원되나요?
A.현재 HS256/384/512(HMAC) 만 지원합니다. RS256·ES256 같은 비대칭 알고리즘은 PEM 키 파싱이 필요해 별도 도구로 분리 검토 중. HMAC 은 단일 비밀로 서명·검증 모두 처리하므로 단순 용도엔 충분.
Q.secret 이 외부로 전송되나요?
A.아닙니다. Web Crypto API 의 `crypto.subtle.importKey` + `subtle.sign` 모두 브라우저에서만 동작 — secret · payload · 결과 토큰 어느 것도 yutils 서버나 외부 API 로 나가지 않습니다.
Q.production 비밀번호로 써도 되나요?
A.테스트 · 로컬 디버깅 목적에 적합합니다. production secret 을 브라우저 도구에 붙여 넣는 것은 일반적으로 권장하지 않아요 — 클립보드 / 브라우저 확장 등 노출 surface 가 있습니다. 실제 발급은 백엔드에서.
재미있는 사실

  • JWT 사양 RFC 7519 는 알고리즘 'none' 을 정의했고, 이게 2015 년 Auth0 가 발견한 대량 취약점의 원인이 됐습니다 — 다수 JWT 라이브러리가 서버가 받은 JWT 의 alg 헤더를 'none' 으로 바꾸면 서명 검증을 통과시키는 결함을 가지고 있었습니다. 이후 라이브러리들이 default 로 'none' 을 차단.

    Auth0 — JWT vulnerabilities (2015)

  • HS256 (HMAC-SHA256) 은 비밀키를 발급자·검증자 양쪽이 똑같이 알아야 합니다. RS256 (RSA) 은 private/public 분리 — 발급자만 private 키로 서명하고 검증자는 public 키로 확인. 서비스가 여러 곳에서 토큰을 검증한다면 RS256 권장.

    RFC 7518 — JOSE Algorithms

  • JWT payload 는 base64url 인코딩일 뿐 암호화가 아닙니다 — 누구나 디코딩해서 평문으로 볼 수 있습니다. 서명은 '변조 방지'를 보장하지만 '내용 비밀'은 보장하지 않으므로, 비밀번호·주민번호 같은 PII 를 payload 에 박지 마세요.

    Auth0 — JWT Claims

관련 도구

이 카테고리 모든 도구 보기 →