CoderTools

JWT 인코더/디코더

JWT 토큰을 안전하게 디코딩, 검증 및 생성

디코딩된 JWT

헤더


                        

페이로드


                        

서명


                        

JSON Web Token (JWT) 완벽 가이드

JWT(JSON Web Token)란 무엇인가요?

JSON Web Token(JWT)은 당사자 간에 정보를 JSON 개체로 안전하게 전송하기 위한 간결하고 독립적인 방법을 정의하는 개방형 표준(RFC 7519)입니다. 이 정보는 디지털 서명되어 있으므로 확인하고 신뢰할 수 있습니다. JWT는 비밀 키(HMAC 알고리즘) 또는 RSA나 ECDSA를 사용하는 공개/비공개 키 쌍을 사용하여 서명할 수 있습니다. Base64Url 인코딩을 사용하여 크기가 작기 때문에 URL, POST 매개변수 또는 HTTP 헤더 내부로 전송할 수 있습니다.

JWT의 구조

JWT는 기술적으로 점(.)으로 구분된 세 부분으로 구성됩니다.

xxxxx.yyyyy.zzzzz
  • 헤더 (Header) : 헤더는 일반적으로 토큰 유형(JWT)과 사용 중인 서명 알고리즘(예: HMAC SHA256 또는 RSA)의 두 부분으로 구성됩니다.
  • 페이로드 (Payload) : 페이로드에는 클레임(Claims)이 포함됩니다. 클레임은 엔터티(일반적으로 사용자) 및 추가 데이터에 대한 진술입니다. 등록된 클레임, 공개 클레임, 비공개 클레임의 세 가지 유형이 있습니다.
  • 서명 (Signature) : 서명 부분을 생성하려면 인코딩된 헤더, 인코딩된 페이로드, 비밀 키, 헤더에 지정된 알고리즘을 가져와서 서명해야 합니다. 서명은 전송 중에 메시지가 변경되지 않았음을 확인하는 데 사용됩니다.

지원되는 알고리즘

이 도구는 모든 표준 알고리즘에 대한 디코딩 및 검증과 대칭 알고리즘 생성을 지원합니다.

  • HS256: HS256 (HMAC SHA-256): 대칭형. 공유 비밀 키가 필요합니다. 빠르고 마이크로서비스에서 일반적입니다.
  • HS384: HS384 (HMAC SHA-384): 대칭형. 더 높은 충돌 저항을 위해 384비트 해시를 사용합니다.
  • HS512: HS512 (HMAC SHA-512): 대칭형. 512비트 해시 사용. 대칭 서명 중 가장 안전합니다.
  • RS256: RS256 (RSA SHA-256): 비대칭형. 서명에는 개인 키를, 검증에는 공개 키를 사용합니다. 공개 API에 이상적입니다.
  • RS384: RS384 (RSA SHA-384): 비대칭형. RS256보다 강력한 해시.
  • RS512: RS512 (RSA SHA-512): 비대칭형. RSA 서명 중 가장 높은 보안.

JWT 클레임 이해하기

클레임은 주제에 대해 주장된 정보 조각입니다. 표준 등록 클레임은 다음과 같습니다.

  • iss (Issuer): iss (Issuer): JWT를 발행한 주체를 식별합니다.
  • sub (Subject): sub (Subject): JWT의 주제인 주체(사용자 등)를 식별합니다.
  • aud (Audience): aud (Audience): JWT가 의도한 수신자를 식별합니다.
  • exp (Expiration Time): exp (Expiration Time): JWT가 수락되어서는 안 되는 만료 시간을 식별합니다.
  • nbf (Not Before): nbf (Not Before): JWT가 수락되기 시작하는 시간을 식별합니다.
  • iat (Issued At): iat (Issued At): JWT가 발행된 시간을 식별합니다.
  • jti (JWT ID): jti (JWT ID): JWT의 고유 식별자를 제공합니다.

언제 JWT를 사용해야 하나요?

  • 권한 부여(Authorization): 가장 일반적인 시나리오입니다. 사용자가 로그인하면 이후의 각 요청에 JWT가 포함되어 사용자가 해당 토큰으로 허용된 경로, 서비스 및 리소스에 액세스할 수 있습니다.
  • 정보 교환: JWT는 당사자 간에 정보를 안전하게 전송하는 좋은 방법입니다. JWT는 서명할 수 있으므로 보낸 사람이 본인임을 확신할 수 있습니다.
  • 무상태 세션: 서버 측 세션과 달리 JWT에는 필요한 모든 사용자 데이터가 포함되어 있어 세션 조회를 위한 데이터베이스 부하가 줄어듭니다.
  • 크로스 도메인 SSO: JWT는 상태가 없고 간결하므로 단일 로그인(SSO) 구현을 위해 다른 도메인 간에 쉽게 전송됩니다.
  • API 보안: 서버가 세션 상태를 유지하지 않는 RESTful API 보안.

중요한 보안 모범 사례: 1. 페이로드에 민감한 데이터(예: 비밀번호)를 넣지 마십시오. 누구나 읽을 수 있습니다(Base64 디코딩). 2. 항상 서명을 확인하십시오. 3. 'exp'(만료) 클레임을 사용하여 토큰 수명을 제한하십시오. 4. HTTPS를 사용하여 토큰 가로채기를 방지하십시오. 5. 토큰을 안전하게 저장하십시오(XSS 공격을 방지하기 위해 LocalStorage보다 HttpOnly 쿠키 권장).

참고 자료

자주 묻는 질문 (FAQ)

JWT는 암호화인가요, 인코딩인가요?

표준 JWT는 인코딩되고 서명되지만 암호화되지는 않습니다. 페이로드의 데이터는 Base64Url로 인코딩되어 있으므로 누구나 디코딩하여 읽을 수 있습니다. 서명은 데이터가 변조되지 않았음을 보장하지만 데이터를 숨기지는 않습니다. 데이터를 숨기려면 JWE(JSON Web Encryption)가 필요합니다.

클라이언트의 어디에 JWT를 저장해야 하나요?

웹 애플리케이션의 경우 `HttpOnly` 쿠키에 JWT를 저장하는 것이 일반적으로 `localStorage`보다 안전한 것으로 간주됩니다. 쿠키는 크로스 사이트 스크립팅(XSS) 공격에 면역이기 때문입니다. 그러나 쿠키는 CSRF에 취약하므로 별도로 방어해야 합니다.

JWT가 도난당하면 어떻게 되나요?

JWT가 도난당하면 도둑은 토큰이 만료될 때까지 사용자를 사칭할 수 있습니다. 이것이 짧은 만료 시간(`exp`)을 사용하고 토큰 취소 전략(예: jti 블랙리스트)을 구현하거나 순환 기능이 있는 일회용 리프레시 토큰을 사용하는 것이 중요한 이유입니다.

이 도구는 내 키를 서버로 전송하나요?

아니요. 이 도구는 전적으로 클라이언트 측에서 실행됩니다. 개인 키, 비밀 키 및 토큰 데이터는 브라우저를 벗어나지 않습니다. 모든 암호화 작업은 JavaScript 라이브러리를 사용하여 로컬에서 수행됩니다.

페이로드를 수동으로 수정할 수 있나요?

로컬에서 페이로드 부분을 수정할 수 있지만 그렇게 하면 원래 키를 기반으로 한 서명이 유효하지 않게 됩니다. 올바른 비밀/개인 키로 다시 서명하지 않는 한 서버는 토큰을 거부합니다.

HS256과 RS256의 차이점은 무엇인가요?

HS256은 대칭 알고리즘입니다(서명 및 검증에 하나의 공유 비밀 키 사용). RS256은 비대칭 알고리즘입니다(서명에는 개인 키, 검증에는 공개 키 사용). RS256은 많은 서비스가 토큰을 검증해야 하지만 생성해서는 안 되는 분산 시스템에 더 적합합니다.

빠른 메뉴

최근 사용 도구 없음