JWT 생성기
JSON Web Token을 생성하며, Header와 Payload를 사용자 정의할 수 있습니다
JWT란?
JWT (JSON Web Token)는 각 방 사이에서 정보를 안전하게 전송하기 위한 개방형 표준 (RFC 7519)입니다. JWT는 Header(헤더), Payload(페이로드), Signature(서명)의 세 부분으로 구성되며, 점으로 구분됩니다. JWT는 인증과 정보 교환 시나리오에서 자주 사용됩니다. JWT의 페이로드는 기본적으로 인코딩된 정보일 뿐 암호화된 비밀 저장소가 아닙니다. 테스트 토큰을 만들 때도 만료 시간, 서명 알고리즘, 키 관리 방식을 신중히 확인해야 합니다.
사용 방법
JWT 생성 흐름
- 서명 알고리즘을 선택하세요 (기본값 HS256)
- 시크릿을 입력하거나 "생성"을 클릭하여 서명 시크릿을 생성하세요
- Payload JSON을 편집하고, 빠른 추가 버튼으로 표준 클레임을 추가하세요
- 발급 시간(iat)과 만료 시간(exp)을 설정하세요
- "JWT 토큰 생성" 버튼을 클릭하세요
- 생성된 토큰을 복사하여 테스트 또는 개발에 사용하세요
토큰 안전
- HMAC 알고리즘에는 강력한 시크릿을 사용하고, RSA/ECDSA 알고리즘에는 개인키를 보호하세요.
- 현실적인 exp, iat, issuer, audience 클레임을 설정하세요. 구문적으로 유효한 JWT도 여전히 불안전하거나 서비스에서 거부될 수 있습니다.
활용 사례
기술 원리
JWT 생성기와 파서는 서로 반대 방향의 처리입니다: 파서는 세 부분을 분리하고, 생성기는 그것들을 조립합니다. 핵심은 Signature 세그먼트를 계산하는 것입니다. 조립 흐름: 1) Header JSON 구성, 예: {"alg":"HS256","typ":"JWT"}; 2) 표준 및 사용자 정의 클레임을 포함한 Payload JSON 구성; 3) Header와 Payload를 각각 Base64URL로 인코딩하여 h_b64와 p_b64 획득; 4) h_b64와 p_b64를 점으로 연결하여 input = h_b64 + '.' + p_b64 형성; 5) alg에 따라 서명 계산: HMAC-SHA256/384/512(secret, input); 6) 서명 결과를 다시 Base64URL 인코딩; 7) 최종 토큰 = input + '.' + sig_b64. HMAC-SHA256 서명: secret을 키로(권장 32바이트 이상) input에 HMAC 적용. 내부적으로 HMAC은 SHA-256을 두 라운드 실행합니다: secret에서 ipad/opad를 유도한 뒤 SHA256(secret XOR ipad || msg) XOR opad를 계산합니다. 키 강도: secret 길이가 보안을 직접적으로 결정합니다. RFC 7518은 HS256 키 길이를 256비트(32바이트) 이상으로 요구합니다. 운영 환경에서는 반드시 암호학적으로 안전한 난수원(예: crypto.randomBytes)을 사용하고, 'secret', 'password', '123456' 같은 문자열은 절대 쓰지 마세요. 흔한 함정: 1) alg 치환 공격: 서버는 alg를 엄격히 검증해야 하며, 토큰 헤더에서 alg를 읽고 해당 알고리즘으로 디스패치해서는 안 됩니다; 2) 약한 키: 너무 짧은 secret은 무차별 대입에 취약합니다; 3) Payload 변조: HMAC이 무결성을 보장하므로 공격자가 payload를 바꾸면 서버 검증이 실패합니다; 4) 토큰 유출: JWT는 폐기할 수 없어 한 번 유출되면 만료를 기다리는 수밖에 없습니다. 본 도구의 범위: HS256/HS384/HS512만 생성합니다. RS256(RSA), ES256(ECDSA) 같은 비대칭 알고리즘은 발급자가 개인 키를 보관해야 하며, 백엔드 서명 서비스나 전용 SDK가 담당합니다. 본 페이지에서는 생성하지 않습니다.
- HMAC-SHA256 서명 핵심: HMAC(secret, header_b64 + '.' + payload_b64)로 256비트 서명을 출력하고 Base64URL로 인코딩합니다.
- HS256 키 길이는 >= 32바이트(256비트)여야 하며, crypto.getRandomValues 또는 crypto.randomBytes로 생성하는 것을 권장합니다. 짧은 키는 사전 공격에 취약합니다.
- 이 도구는 HMAC 계열 서명(HS256/HS384/HS512)만 생성합니다. RS256, ES256 같은 비대칭 알고리즘은 발급자가 개인 키를 보관해야 하며 본 도구에서는 생성하지 않습니다——해당 토큰이 필요하다면 백엔드 서명 서비스나 전용 SDK를 사용하세요.
- iat/exp/nbf는 모두 초 단위 Unix 타임스탬프(밀리초 아님)입니다. 서버는 일반적으로 exp > now(), nbf <= now(), iat <= now()를 요구합니다.
- alg=none 공격: 허용된 알고리즘의 서버 측 화이트리스트를 유지하세요(예: ['HS256']). 토큰 헤더에서 알고리즘을 동적으로 선택하면 안 됩니다. 많은 JWT 라이브러리가 과거에 기본적으로 alg=none을 허용했으며, 이는 알려진 취약점입니다.
- JWT는 발급 후 폐기할 수 없으며, 유일한 대안은 exp를 기다리는 것입니다. 능동 폐기에는 jti 블랙리스트를 유지하거나 단기 액세스 토큰과 리프레시 토큰을 함께 사용하세요.
예시
기본 HS256 예시
헤더: {"alg":"HS256","typ":"JWT"}
페이로드: {"sub":"user-123","name":"Alice","role":"admin","iat":1705312800,"exp":1705399200}
시크릿: my-super-secret-key-32-bytes-long
토큰: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNTMxMjgwMCwiZXhwIjoxNzA1Mzk5MjAwfQ.7Hk2L9oP3qR1mN4vK8xJ2wE5yT6sB0fA9cZ1dG3hI4Uiat와 exp로 만료 시간 조정
Header: {"alg":"HS256","typ":"JWT"}
Payload: {"iss":"https://auth.example.com","sub":"user-456","aud":"api.example.com","iat":1705312800,"exp":1705316400}
Secret: another-strong-secret-32-bytes-long
페이지는 헤더와 페이로드를 Base64URL로 인코딩하고 점으로 이어붙인 뒤 공유 시크릿으로 HMAC-SHA256을 적용합니다. Token 필드에는 Authorization 헤더에 바로 붙여 넣을 수 있는 3 세그먼트 문자열이 출력됩니다.사용자 정의 클레임
헤더: {"alg":"HS256","typ":"JWT"}
페이로드: {
"sub": "user-789",
"name": "Bob",
"role": "editor",
"tenant": "acme-corp",
"permissions": ["read:docs", "write:docs"],
"scope": "docs.read docs.write",
"iat": 1705312800,
"exp": 1705399200,
"jti": "550e8400-e29b-41d4-a716-446655440000"
}자주 묻는 질문
JWT가 로컬에서 생성되나요?
네. 헤더, 페이로드, 시그니처는 Web Crypto API를 사용해 브라우저 안에서 계산됩니다. 서명용 시크릿이나 개인키는 페이지를 떠나지 않습니다. 다만 토큰 자체는 로그에 남거나 노출될 수 있는 데이터로 취급해야 하며, 실제 서비스에 붙여 넣을 때는 특히 주의하세요.
어떤 서명 알고리즘을 지원하나요?
이 도구는 HS256/HS384/HS512(공유 시크릿 기반 HMAC)를 생성합니다. RS256/RS384/RS512(RSA)나 ES256/ES384/ES512(ECDSA) 같은 비대칭 알고리즘은 본 도구에서 생성하지 않으며, 검증 측에서 요구한다면 백엔드 서명 서비스나 전용 SDK를 사용하세요. 운영 환경에서는 alg=none을 피하세요——제대로 된 검증기는 비서명 토큰을 거부합니다.
페이로드에는 무엇을 넣나요?
sub, iss, aud, exp, iat, nbf 같은 표준 클레임과 서비스에서 사용하는 커스텀 클레임을 넣습니다. 페이로드는 작게 유지하세요. JWT는 헤더에 실려 다니므로 매 요청마다 함께 커집니다. 비밀번호, 신용카드 전체 번호 등 민감 정보는 절대 넣지 마세요. 페이로드는 Base64URL일 뿐 암호화되지 않습니다.
만료 시간은 어떻게 설정하나요?
exp에 토큰이 더 이상 유효하지 않게 될 시점의 Unix 타임스탬프(밀리초가 아니라 초)를 넣으세요. exp 없는 토큰도 기술적으로는 합법이지만, 대부분의 운영 서비스는 exp를 요구합니다. 액세스 토큰은 보통 5~60분, 리프레시 토큰은 7~30일이 일반적입니다.
내가 만든 JWT가 왜 검증에 실패하나요?
흔한 원인은 헤더의 alg가 검증기가 기대하는 값과 다른 경우, 시크릿/키가 다른 경우, 페이로드 클레임(iss, aud)이 서버 설정과 맞지 않는 경우, 발급자와 검증자의 시계 차가 허용 여유(보통 ±60초)를 넘은 경우, 수동 편집으로 Base64URL 인코딩이 깨진 경우(줄바꿈을 넣지 마세요) 등입니다.
내 시크릿이나 개인키가 서버로 전송되나요?
아니요. 서명은 Web Crypto를 통해 전적으로 브라우저 안에서 이뤄집니다. 그래도 운영용 서명 키는 어떤 웹 도구에도 붙여 넣지 마세요. 비운영 키로 테스트한 뒤, 실제 서명은 자체 백엔드에서 하세요.
HS256과 RS256 중 무엇을 써야 하나요?
HS256은 양쪽이 시크릿을 공유해야 하므로, 같은 서비스에서 토큰을 발급하고 검증하는 경우에만 적합합니다. RS256(또는 ES256)은 발급자가 개인키를 보관하고 모든 소비자가 공개키로 검증할 수 있게 해 주므로, OAuth/OIDC나 멀티 서비스 아키텍처에서 올바른 선택입니다. 이 도구는 HS 계열 토큰만 생성합니다. RS256/ES256가 필요하면 백엔드 서명 서비스나 전용 SDK를 사용하세요.