JWT 생성기

서명된 JSON Web Token을 생성하기 위한 빠르고 무료인 온라인 도구인 JWT 생성기에 오신 것을 환영합니다. 인증 흐름을 테스트하거나, API를 구축하거나, 통합을 디버깅하거나, JWT가 내부적으로 어떻게 작동하는지 학습하려는 경우, 이 생성기를 통해 토큰 헤더, 페이로드 클레임 및 HMAC 서명 알고리즘을 완벽하게 제어할 수 있습니다. 한 번의 클릭으로 유효한 HS256, HS384 또는 HS512 토큰을 출력하고 각 세그먼트를 나란히 검사해 보세요.

JSON Web Token이란 무엇인가요?

JSON Web Token (JWT)은 RFC 7519에 정의된 콤팩트하고 URL에 안전한 자격 증명 형식입니다. JWT는 두 당사자 간에 주체에 대한 클레임을 전달하고 암호화 서명을 통해 무결성을 증명합니다. 토큰 자체가 필요한 모든 정보를 포함하고 있기 때문에(self-contained), 수신자는 발급자에게 다시 확인하지 않고도 토큰을 검증할 수 있습니다. 이러한 속성 덕분에 JWT는 현대 웹 및 모바일 애플리케이션의 상태 없는(stateless) 인증의 핵심이 되었습니다.

모든 JWT는 점(.)으로 연결된 세 개의 base64url 인코딩된 부분으로 구성됩니다:

• 헤더 (Header) — 토큰 유형(typ)과 서명 알고리즘(alg)을 선언하는 JSON 객체입니다.
• 페이로드 (Payload) — 사용자 ID, 만료 시간 및 기타 사용자 정의 데이터와 같은 클레임을 담고 있는 JSON 객체입니다.
• 서명 (Signature) — 인코딩된 헤더와 페이로드를 변조로부터 보호하는 인코딩된 헤더와 페이로드에 대한 HMAC 또는 RSA 서명입니다.

JWT 생성기 작동 방식

이 도구는 RFC 7519 §7.1의 정확한 JWT 서명 절차를 따릅니다:

1. 헤더 JSON을 콤팩트한 형식(공백 없음)으로 직렬화하고 base64url로 인코딩합니다.
2. 페이로드 JSON에 대해서도 동일하게 수행합니다.
3. 두 부분을 점(.) 구분 기호로 연결합니다. 이것이 서명 입력값입니다.
4. 비밀키와 선택한 SHA-2 알고리즘을 사용하여 서명 입력의 HMAC을 계산합니다.
5. 결과 서명 바이트를 base64url로 인코딩합니다.
6. 모든 것을 header.payload.signature 형식으로 연결합니다.

이 생성기만의 특징

• 3개 세그먼트 색상 시각화 — 헤더(장미색), 페이로드(보라색), 서명(청록색)으로 구분되어 각 부분을 즉시 식별할 수 있습니다.
• 빠른 클레임 팔레트 — iss, sub, aud, iat, nbf, jti를 원클릭으로 삽입합니다.
• 만료 도우미 — 1시간, 1일, 7일, 30일 프리셋 버튼이 정확한 Unix 타임스탬프를 자동으로 계산합니다.
• 실시간 토큰 미리보기 — 입력함에 따라 인코딩된 헤더와 페이로드가 실시간으로 업데이트되어 수정 사항이 토큰을 어떻게 바꾸는지 확인할 수 있습니다.
• 스마트 헤더 동기화 — 알고리즘을 전환하면 헤더의 alg 필드가 자동으로 업데이트됩니다.
• Base64 비밀키 토글 — 비밀키가 base64로 저장된 경우(이진 키에 대한 JWS 관례), 옵션을 활성화하면 도구가 서명 전 이를 디코딩합니다.
• 세그먼트별 복사 버튼 — 헤더, 페이로드, 서명 또는 전체 토큰을 개별적으로 복사합니다.
• 클레임 요약 — 인식된 표준 클레임은 설명 및 해당되는 경우 사람이 읽을 수 있는 타임스탬프와 함께 목록으로 표시됩니다.

올바른 알고리즘 선택하기

이 도구가 지원하는 세 가지 HMAC 변형은 기본 SHA-2 해시 및 서명 길이를 제외하고는 기능적으로 동일합니다:

• HS256 — SHA-256을 사용하는 HMAC. 256비트 서명. 거의 모든 JWT 발급 라이브러리의 기본값이자 가장 널리 호환되는 선택입니다.
• HS384 — SHA-384를 사용하는 HMAC. 384비트 서명. 향후의 암호 해독 분석에 대해 약간 더 높은 보안 여유를 제공합니다.
• HS512 — SHA-512를 사용하는 HMAC. 512비트 서명. 정책상 가장 긴 표준 해시가 필요한 경우 유용합니다.

세 가지 모두 서명자와 검증자가 모두 보유한 공유 비밀키에 의존합니다. RFC 7518 §3.2는 키 길이가 해시 출력 길이 이상이어야 한다고 규정합니다: HS256은 256비트, HS384는 384비트, HS512는 512비트입니다.

표준 등록 클레임

RFC 7519 §4.1은 JWT 발급자와 검증자가 인식해야 하는 소수의 표준 클레임 세트를 정의합니다. 모두 선택 사항이지만 널리 지원됩니다:

• iss (발급자) — 토큰을 생성한 주체를 식별합니다. 주로 URL이나 서비스 이름입니다.
• sub (주체) — 토큰의 대상이 누구인지 식별하며, 일반적으로 사용자 ID입니다.
• aud (대상) — 토큰의 수신자를 식별합니다. 단일 문자열 또는 배열일 수 있습니다.
• exp (만료 시간) — 이 시간 이후에는 토큰을 거부해야 하는 Unix 타임스탬프입니다.
• nbf (활성 시작 시간) — 이 시간 이전에는 토큰을 수락해서는 안 되는 Unix 타임스탬프입니다.
• iat (발급 시간) — 토큰이 생성된 시간을 기록하는 Unix 타임스탬프입니다.
• jti (JWT ID) — 토큰을 개별적으로 취소하거나 추적할 수 있게 해주는 고유 식별자입니다.

이 도구 사용 방법

1. 서명 알고리즘 선택 — HS256, HS384 또는 HS512를 클릭합니다. 헤더가 일치하도록 자동으로 업데이트됩니다.
2. 헤더 편집 (선택 사항) — 기본 헤더에는 alg와 typ이 포함되어 있습니다. 검증자에게 필요한 경우 사용자 정의 kid (키 ID)를 추가하세요.
3. 페이로드 빌드 — 클레임을 JSON으로 직접 입력하거나 빠른 클레임 버튼을 클릭하여 표준 필드를 삽입합니다. 만료 도우미는 선택한 상대 기간에 대해 올바른 Unix 타임스탬프를 작성합니다.
4. 비밀키 설정 — HMAC 공유 비밀키를 입력합니다. 눈 아이콘을 토글하여 내용을 확인할 수 있습니다. 비밀키가 base64로 인코딩된 경우 체크박스를 활성화하여 서명 전 디코딩되도록 합니다.
5. JWT 생성 — JWT 생성 버튼을 클릭합니다. 전체 토큰, 3개의 세그먼트 카드, 구조 다이어그램 및 인식된 클레임 요약이 함께 렌더링됩니다.
6. 필요한 항목 복사 — 세그먼트별 복사 버튼 또는 토큰 복사 버튼을 사용하여 인코딩된 값을 Postman, curl 또는 클라이언트 앱으로 가져갑니다.

일반적인 사용 사례

인증 및 권한 부여

• 성공적인 로그인 후 액세스 토큰을 발급합니다.
• 사용자 ID(sub)와 역할 또는 권한 클레임을 인코딩합니다.
• 수명이 짧은 토큰(15~60분)을 서명하고 필요에 따라 갱신합니다.

API 통합 테스트

• 만료되었거나, 미래 날짜이거나, 형식이 잘못된 클레임에 대해 API가 어떻게 반응하는지 테스트하기 위해 모의 토큰을 만듭니다.
• 단위 테스트 및 CI 파이프라인을 위한 픽스처 JWT를 생성합니다.
• 실제 인증 서버를 통하지 않고 로컬 환경에서 프로덕션과 유사한 토큰을 재현합니다.

Single Sign-On (SSO) 디버깅

• 알려진 정상 JWT와 제공업체가 보내는 JWT를 비교하여 사양 차이를 찾습니다.
• 업스트림 발급자가 사용하는 서명 알고리즘과 키 ID(kid)를 확인합니다.

자주 묻는 질문

여기서 생성된 JWT는 실제로 유효한 토큰인가요?

네. 토큰은 표준화된 인코딩 헤더와 페이로드에 대해 HMAC으로 서명됩니다. 동일한 비밀키를 사용하는 모든 JWT 라이브러리는 이를 성공적으로 검증할 것입니다.

내 토큰이 왜 다른 곳에서 생성한 것과 똑같이 보이나요?

JWT는 결정론적이기 때문입니다. 동일한 헤더, 페이로드 및 비밀키가 주어지면 모든 표준 준수 라이브러리는 정확히 동일한 문자열을 생성합니다. 차이가 있다면 JSON 직렬화 순서, 키 철자 및 비밀키 인코딩이 모두 일치하는지 확인하세요.

생성한 것을 확인하기 위해 JWT를 디코딩할 수 있나요?

네. 이 도구를 JWT 디코더와 함께 사용하여 세그먼트를 검사하세요. 디코딩은 base64url 단계만 되돌리는 것이며, 서명을 검증하려면 여전히 비밀키가 필요합니다.

왜 내 비밀키가 너무 짧다고 거부되나요?

RFC 7518은 키가 최소한 해시 출력 길이와 같아야 한다고 권장합니다(HS256의 경우 256비트). 도구 자체는 최소 길이를 강제하지 않지만, 올바르게 구현된 검증자는 짧은 키를 거부할 수 있습니다. 실제 사용 시에는 무작위로 생성된 32바이트 이상의 비밀키를 사용하세요.

이 도구는 RS256, ES256 또는 EdDSA를 지원하나요?

아직은 지원하지 않습니다. 이 도구는 공유 문자열만 필요한 HMAC 기반 알고리즘에 집중하고 있습니다. 비대칭 알고리즘(RS*, PS*, ES*, EdDSA)은 전용 도구에 더 적합한 키 쌍 및 PEM 처리가 필요합니다.

내 비밀키와 페이로드가 서버로 전송되나요?

서명을 계산하기 위해 폼 데이터가 HTTPS를 통해 전송됩니다. 요청 수명 기간을 넘어서는 어떠한 데이터도 로깅되거나 저장되지 않습니다. 그럼에도 불구하고 실제 서비스 비밀키는 입력하지 마세요. 공개 테스트 환경으로 간주하십시오.

추가 리소스

• RFC 7519 - JSON Web Token (JWT)
• RFC 7515 - JSON Web Signature (JWS)
• RFC 7518 - JSON Web Algorithms (JWA)
• JSON Web Token - 위키백과