JWT 인코더 (생성 및 서명)
헤더와 페이로드 JSON으로부터 HS256, HS384, HS512 중 하나로 HMAC 서명된 JWT(JSON Web Token)를 브라우저 안에서 생성합니다. 비밀 키를 포함한 입력 내용은 서버로 전송되지 않습니다.
지원하는 HMAC 서명 알고리즘 목록
| 알고리즘 | 해시 함수 | 서명 길이 | 설명 |
|---|---|---|---|
| HS256 | SHA-256 | 256비트 (32바이트) | 가장 널리 쓰이는 기본 HMAC 서명 방식으로, OAuth 2.0 및 OpenID Connect의 ID 토큰 등 많은 구현에서 표준으로 채택하고 있다. |
| HS384 | SHA-384 | 384비트 (48바이트) | HS256보다 긴 서명으로 보안 여유를 높이고 싶을 때 사용하는 중간 단계의 선택지. |
| HS512 | SHA-512 | 512비트 (64바이트) | 가장 긴 서명 길이를 가지며, 충분히 긴 무작위 비밀 키와 함께 사용하는 경우가 많다. |
팁
- 생성된 JWT는 브라우저 내 Web Crypto API만으로 서명되며, 비밀 키를 포함한 입력 내용은 toolbase.cc 서버로 전송되지 않습니다.
- 서명 알고리즘(HS256/HS384/HS512)을 변경하면 헤더 JSON의
alg필드가 자동으로 갱신됩니다.kid등 다른 클레임을 추가하려면 헤더를 직접 편집하세요. - 이 도구는 HMAC(대칭 키) 방식만 지원합니다. RS256, ES256과 같은 공개 키 방식의 서명이 필요하다면 Node.js 등 서버 사이드 라이브러리를 이용하세요.
- 헤더나 페이로드를 수정한 뒤에는 반드시 "JWT 생성"을 다시 눌러야 합니다. 누르기 전까지는 이전 입력 내용으로 생성된 오래된 JWT가 그대로 표시됩니다.
- 생성한 JWT의 내용을 바로 확인하고 싶다면 자매 도구인 JWT 디코더에 붙여넣어 헤더와 페이로드를 검증할 수 있습니다.
자주 묻는 질문
alg 필드 값이 일치하지 않으면, 다른 구현에서 이 JWT를 검증할 때 오류가 발생할 수 있으므로 두 값을 항상 일치시켜야 합니다.
여담 ― JWT 서명이 "브라우저만으로" 완결될 수 있는 이유
JWT 서명 알고리즘은 크게, 송신자와 수신자가 같은 비밀 키를 공유하는 "대칭 키 방식(HMAC, 즉 HS256/HS384/HS512)"과 개인 키로 서명하고 공개 키로 검증하는 "공개 키 암호 방식(RS256·ES256 등)"으로 나뉩니다. 전자는 W3C가 표준화한 Web Crypto API(SubtleCrypto)의 crypto.subtle.sign()을 사용하면 외부 라이브러리 없이 브라우저만으로 계산을 완결할 수 있기 때문에, 이 도구는 의도적으로 HMAC 방식만 지원하도록 범위를 좁혔습니다.
HMAC 서명의 안전성은 헤더나 페이로드의 내용이 아니라 비밀 키를 추측하기 어려운 정도에 전적으로 달려 있습니다. RFC 7518(JSON Web Algorithms)은 HS256의 경우 256비트(32바이트) 이상의 키 길이를 권장하고 있으며, 짧은 단어나 사전에 나올 법한 문자열을 비밀 키로 사용하면 무차별 대입 공격으로 서명이 위조될 위험이 있습니다. 실제 운영 환경에서는 난수 생성기로 만든 충분히 긴 무작위 문자열을 비밀 키로 사용해야 합니다.
이 도구는 API 개발 중 동작 확인이나 Webhook 서명 검증 로직 테스트를 위한 개발자용 유틸리티입니다. 입력한 비밀 키는 브라우저 메모리 내에서만 처리되며 외부로 전송되지 않지만, 공유 단말기나 브라우저 확장 프로그램이 클립보드나 입력 내용을 수집할 위험이 전혀 없는 것은 아닙니다. 동작 확인 목적이라 하더라도 실제 운영 환경에서 사용 중인 비밀 키를 이런 도구에 입력하지 않는 것을 강력히 권장합니다.