DevUtils
기술 가이드
보안 & 인증4분 읽기

JWT (JSON Web Token) 구조와 실무 보안 취약점 완벽 방어 가이드

JWT의 구조와 표준 클레임, 대칭키(HS256) vs 비대칭키(RS256) 서명 차이, alg: none 취약점 대응, 토큰 저장소(LocalStorage vs Cookie) 보안 전략을 정리합니다.

실시간 온라인 도구 바로가기

JWT 디코더 & 생성기

서버 전송 없이 100% 브라우저 로컬에서 안전하게 직접 테스트하고 검증해보세요.

도구 실행하기

JSON Web Token (RFC 7519)의 해부학: Header, Payload, Signature

JWT(JSON Web Token)는 당사자 간의 정보를 안전하고 간결하게 전송하기 위한 URL-Safe 개방형 표준(RFC 7519)입니다. JWT는 점(.)으로 구분된 3가지 부분으로 구성됩니다:

  1. Header(헤더): 토큰의 타입("typ": "JWT")과 서명 알고리즘("alg": "HS256" 또는 "RS256")을 정의합니다.
  2. Payload(내용/클레임): 토큰 발급 대상 사용자 식별자, 권한, 만료 시간 등의 실제 데이터(Claim)를 담습니다.
  3. Signature(서명): Base64URL 인코딩된 헤더와 페이로드를 합친 뒤 비밀키로 암호학적 해시를 생성하여, 전송 중 위변조가 없었음을 검증합니다.
TEXTDevUtils Code Reference
// 유효한 JWT 전체 토큰 예시 (DevUtils JWT Decoder에서 직접 테스트 가능):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

// 1. 헤더 (Base64URL):
// eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 -> {"alg":"HS256","typ":"JWT"}

// 2. 페이로드 (Base64URL):
// eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
// -> {"sub":"1234567890","name":"John Doe","iat":1516239022}

// 3. 서명:
// SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

반드시 검증해야 하는 6가지 표준 JWT 클레임

보안 취약점을 예방하기 위해 백엔드 API에서 반드시 검증해야 하는 표준 클레임입니다:

  • exp (Expiration Time): 토큰 만료 시점(Unix 타임스탬프). 유효기간이 지난 토큰은 즉시 거절해야 합니다. 액세스 토큰은 보통 5~15분의 짧은 만료 시간을 권장합니다.
  • nbf (Not Before): 토큰이 활성화되는 시점. 이 시간 이전의 요청은 거부해야 합니다.
  • iat (Issued At): 토큰 발급 시각.
  • iss (Issuer): 토큰 발급자. 우리 인증 서버에서 발행된 것인지 검증합니다.
  • aud (Audience): 토큰 수신 대상. 다른 서비스용으로 발급된 토큰이 우리 API에 오남용되는 것을 막습니다.
  • sub (Subject): 토큰 주체(사용자 고유 식별자 PK).

대칭키(HS256) vs 비대칭키(RS256/ES256) 서명 방식 비교

  • HMAC-SHA256 (HS256): 토큰 서명과 검증에 동일한 단일 비밀키(Secret Key)를 사용합니다. 여러 마이크로서비스가 토큰을 검증해야 하는 경우 모든 서비스가 비밀키를 공유해야 하므로, 단 하나의 서비스만 침해되어도 공격자가 임의의 유효한 토큰을 위조할 수 있습니다.
  • RSA / ECDSA (RS256 / ES256): 공개키 암호화 방식을 사용합니다. 중앙 인증 서버만이 개인키(Private Key)로 서명하고, 각 API 게이트웨이나 마이크로서비스는 외부에 공개된 공개키(Public Key)만으로 토큰을 안전하게 검증합니다. 현대 분산 아키텍처에서는 RS256/ES256이 표준으로 권장됩니다.

실무에서 발생하는 주요 JWT 보안 취약점과 방어책

  1. alg: "none" 취약점: 초기 라이브러리들에서 공격자가 헤더에 "alg": "none"을 지정하고 서명을 비워두었을 때 유효한 것으로 처리하는 심각한 버그가 있었습니다. 프로덕션 검증 로직에서는 "none" 알고리즘을 명시적으로 차단해야 합니다.
  2. 알고리즘 혼동 공격(Key Confusion Attack): RS256을 기대하는 서버에 공격자가 HS256 알고리즘과 함께 서버의 공개키 텍스트를 대칭키 비밀번호로 전달하여 서명을 위조하는 공격입니다. 서버는 사전에 허용된 알고리즘 목록만 엄격히 수용해야 합니다.
  3. 취약한 비밀키: 짧고 예측 가능한 비밀번호는 사전 대입 공격에 노출됩니다. HS256 비밀키는 최소 256비트 이상의 무작위 난수를 사용해야 합니다.

프론트엔드 토큰 저장소 비교: LocalStorage vs HttpOnly 쿠키

  • LocalStorage: 자바스크립트에서 쉽게 읽고 쓸 수 있지만, XSS(크로스 사이트 스크립팅) 취약점이 발생할 경우 악성 스크립트에 의해 토큰이 그대로 탈취됩니다.
  • HttpOnly, Secure, SameSite 쿠키: 브라우저 자바스크립트 엔진에서 접근이 원천 차단되므로 XSS 토큰 탈취를 방어할 수 있습니다. 단, CSRF 공격에 대비하기 위해 SameSite 설정을 Lax 또는 Strict로 지정해야 합니다.
  • 권장 실무 패턴: Access Token은 단기 메모리(리액트 상태 등)에 보관하고, Refresh Token은 HttpOnly 쿠키에 담아 토큰 회전(Rotation)을 적용하는 방식이 안전합니다.
태그:JWT보안사용자 인증OAuth 2.0웹 토큰
실시간 온라인 도구 바로가기

JWT 디코더 & 생성기

온라인 무료 JWT 토큰 디코더 및 검증기. HS256/356/512 서명 검증, Header 및 Payload 파싱, 만료일 자정 확인. 브라우저에서 안전하게 동작합니다.

도구 실행하기