JWT(JSON Web Token) 에 대해 알아보겠습니다.

Ⅰ. JWT(JSON Web Token) 란 ?

 클라이언트와 서버 간에 정보를 안전하게 전달하기 위한 토큰 기반 인증 방식입니다. 서버가 세션 상태를 저장하지 않는 무상태(Stateless) 특성을 가지며, 토큰 자체에 인증 정보가 포함되어 있어 확장성과 성능 면에서 큰 강점을 가집니다. 

현재 RESTful API 환경에서 가장 널리 쓰이는 표준 인증 수단입니다.

Ⅱ. JWT(JSON Web Token) 목적

 ⅰ. 사용자 인증 (Authentication)
   → 로그인 성공 시 서버가 JWT를 발급하며, 이후 클라이언트는 이 토큰을 제시하여 신원을 증명합니다.
 ⅱ. 권한 부여 (Authorization)
   → 토큰 내부에 사용자 역할(Role)이나 권한 정보를 담아, 특정 API에 접근할 수 있는지 판단하는 기준으로 사용합니다.
 ⅱ. 무상태성 (Stateless) 유지
   → 서버에 세션 정보를 저장하지 않으므로, 서버 확장(Scale-out)이나 마이크로서비스 환경 구축에 유리합니다.

Ⅲ. JWT(JSON Web Token) 구조

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

Header . Payload . Signature

 ⅰ. Header (헤더) : 토큰의 타입과 서명 알고리즘 정보를 담습니다.
   1) alg: 서명 알고리즘 (예: HS256, RSA)
   2) 토큰 타입 (JWT)
 ⅱ. Payload (페이로드) : 실제 전달할 정보를 담는 곳으로, 각 정보 조각을 클레임(Claim)이라고 합니다.
   1) 표준 클레임: sub(사용자 ID), iat(발급 시간), exp(만료 시간) 등
   2) 사용자 정의 클레임: name, email, role 등
 ※ 주의: 페이로드는 단순 인코딩(Base64)된 값이므로, 비밀번호나 주민번호 같은 민감 정보는 절대 포함해선 안 됩니다.
 ⅲ. Signature (서명) : 헤더와 페이로드를 합친 뒤 비밀키로 서명한 값이며, 토큰이 전송 도중 변조되지 않았음을 검증하는 무결성 확인 용도로 사용됩니다.

Ⅳ. JWT(JSON Web Token) 인증 흐름 ( 동작 원리)

 ⅰ. 로그인 요청 : 클라이언트가 ID/PW를 서버로 전송
 ⅱ. 토큰 발급 : 인증 성공 시 서버가 JWT 생성 후 반환
 ⅲ. 토큰 전달 : 이후 요청 시 HTTP 헤더에 토큰 포함 (Authorization: Bearer <Token>)
 ⅳ. 토큰 검증 : 서버는 서명과 만료 시간을 확인 후 요청 처리 (별도 세션 조회 없음)

Ⅴ. JWT(JSON Web Token) 주요 활용 분야

 ⅰ. RESTful API 인증: 웹, 모바일, 외부 연동 시 표준 인증
 ⅱ. 마이크로서비스 (MSA): 중앙 인증 서버 없이 서비스 간 신뢰 구축
 ⅲ. SSO (Single Sign-On): 하나의 토큰으로 여러 서비스 통합 로그인
 ⅳ. 시스템 연동: 서버 간 통신(M2M)의 접근 제어 수단

Ⅵ. JWT(JSON Web Token) 서명 알고리즘 비교

방식	알고리즘	특징
대칭키	HS256	하나의 비밀키를 서버들이 공유. 구현이 간단하나 키 유출 시 위험 큼
비대칭키	RS256	개인키로 서명, 공개키로 검증. 키 관리가 안전하여 MSA 환경에 적합
타원곡선	ES256	타원곡선 암호 기반. 높은 보안성과 빠른 성능을 동시에 제공

Ⅶ. 쿠팡 JWT(JSON Web Token) 보안 사고

 ⅰ. 사고 개요
쿠팡에서 퇴사자가 유출한 서명키가 장기간 방치되어 발생한 사고입니다. 공격자는 이 키로 위조 토큰을 생성하고, 사용자 ID를 순차적으로 대입하여 대규모 개인정보를 탈취했습니다. 이는 기술적 결함보다는 관리적 소홀이 원인이었습니다.
 ⅱ. 근본 원인
  1) 서명키 장기 미교체 및 접근 통제 실패
  2) 예측 가능한 순차적 사용자 ID 구조
  3) 과도하게 긴 토큰 만료 시간
 ⅲ. 보안 강화 및 대응 방안
  1) 서명키 주기적 교체 (Key Rotation): 퇴사자 발생 시 즉시 폐기 및 교체
  2) 짧은 만료 시간 (Short-lived Token): Access Token은 15~30분으로 제한하고 Refresh Token 별도 운영
  3) 사용자 ID 난수화: 순차 증가 ID 대신 UUID를 사용하여 열거(Enumeration) 공격 방지
  4) 전송 구간 암호화: HTTPS 필수 적용으로 토큰 탈취 방지
  5) 최소 권한 원칙: 페이로드에 민감 정보(개인정보, 결제정보) 절대 포함 금지