JWT(JSON Web Token)

dustle·2026년 5월 31일

JWT(JSON Web Token) 구조

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

xxxxx.yyyyy.zzzzz
header.payload.signature

각 부분은 Base64Url로 인코딩됩니다.

토큰의 메타데이터를 담습니다.

{
  "alg": "HS256",
  "typ": "JWT"
}
  • alg: 서명 알고리즘을 지정합니다 (HS256, RS256, ES256 등)
  • typ: 토큰 타입을 나타냅니다 (보통 JWT)

Payload

실제로 전달할 데이터(Claim)를 담습니다. Claim은 세 가지로 나뉩니다.

Registered Claims (표준 정의)

  • iss (issuer): 발급자
  • sub (subject): 토큰의 주체 (보통 사용자 ID)
  • aud (audience): 수신자
  • exp (expiration): 만료 시각 (Unix timestamp)
  • nbf (not before): 이 시각 이전에는 사용할 수 없습니다
  • iat (issued at): 발급 시각
  • jti (JWT ID): 토큰 고유 식별자

Public Claims

  • IANA JWT 레지스트리에 등록해서 사용하거나, 충돌을 방지하기 위해 URI 형식으로 정의합니다

Private Claims

  • 발급자와 사용자가 합의하여 사용하는 커스텀 클레임입니다 (예: role, userId)
{
  "sub": "1234567890",
  "name": "John Doe",
  "role": "USER",
  "iat": 1700000000,
  "exp": 1700003600
}

Payload는 인코딩만 될 뿐 암호화되지 않기 때문에 누구나 디코딩하여 내용을 볼 수 있습니다. 따라서 민감 정보를 담으면 안 됩니다.

Signature

Header와 Payload의 위변조를 검증하는 부분입니다.

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)
  • Header에 지정된 알고리즘으로 서명합니다
  • 서버는 토큰을 받을 때 같은 방식으로 서명을 다시 계산하여 일치 여부를 확인합니다
  • 비밀키(secret)를 모르면 위조할 수 없습니다
  • RS256/ES256 같은 비대칭 알고리즘은 개인키로 서명하고, 공개키로 검증합니다

동작 흐름

  1. 사용자가 로그인하면 서버가 JWT를 발급합니다
  2. 클라이언트는 이후 요청의 Authorization: Bearer <token> 헤더에 JWT를 포함시킵니다
  3. 서버는 서명 검증과 만료 시간 확인을 거쳐 통과한 요청만 처리합니다
  4. 세션을 서버에 저장하지 않기 때문에 무상태(stateless) 구조로 운영할 수 있습니다

0개의 댓글