JWT

아래의 페이지에서 예시 토큰과 Decoded 값을 확인 할 수 있다

• JWT.IO 페이지

JWT

• 안정적인 인증과 정보 전달을위해 사용되는 토큰 형식으로, 아래와 같은 구조를 가진다

  [HEADER].[PAYLOAD].[SIGNATURE]
  

• 주로 로그인 인증 후 사용자 정보를 담아 클라이언트에 전달하거나, API 요청 시 인증 토큰으로 사용된다

JWT 토큰은 Docode시 3가지 형태로 나뉜다.

구조

1. HEADER

• 알고리즘과 타입을 명시하는 부분

  • alg: 토큰을 서명하는 데 사용된 해싱 알고리즘 (예: HS256)
  • typ: 토큰 타입, 일반적으로 JWT로 고정됨

  # Encoded
  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
  
  # Decoded
  {
    "alg": "HS256",
    "typ": "JWT"
  }
  

2. PAYLOAD

• 실제 담고 싶은 정보들이 포함되는 부분
• key: value 한쌍의 클레임(claim)으로 구성
  • 등록된 클레임 (Registered Claim): iss, exp, sub, aud 등
  • 공개 클레임 (Public Claim): URI 형식의 키 사용 (충돌 방지 목적)
  • 비공개 클레임 (Private Claim): 애플리케이션 내부에서 정의한 키

# Encoded
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

# Decoded
{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022,
  "https://google.com": ture # 공개 클레임의 형태 (ex.uri)
  "user_name": "kim" # 비공개 클레임
}

3. VERIFY SIGNATURE

• 토큰의 무결성을 검증하는 부분

• 아래의 세가지 정보를 조합하여 생성한다

  HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
  )
  

• 이 signature를 통해 토큰이 변조되었는지 확인 할 수 있다

• 보통 Signature는 디코딩하지 않고, 서버가 이 부분을 통해 JWT의 유효성을 검증한다

  # Encoded
  SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
  

특징

JWT를 사용하면 인증상태를 서버에 저장하지 않고 사용자를 인증할 수 있으므로,
인증이 간단해지고, 확장성이 있으며, 서버의 부하를 줄일 수 있다.

1. Stateless(무상태) 인증

• JWT는 토큰 자체에 사용자 정보를 담고 있어, 서버에서 세션을 저장할 필요 X

• 클라이언트 요청마다 JWT를 함께 보내면, 서버는 토큰만으로 사용자 인증 가능
  → 서버 확장성에 유리

  세션 기반 인증시

  • 세션 방식은 사용자 수가 늘면 서버에 저장되는 세션 정보도 많아짐 → 서버 부하 증가

2. 토큰 자체에 정보가 포함

• Payload에 사용자의 다양한 정보를 담을 수 있음
• 요청마다 별도의 사용자 조회 없이 빠르게 처리 가능
• 예: 관리자 권한 확인시, 토큰에서 바로 role: admin 확인 가능

3. 서버 간 인증 정보 공유가 쉬움

• 중앙 인증 서버에서 발급한 JWT를 다른 서버들이 검증만 하면 되므로, 분산 시스템에 적합

4. 모바일 / SPA 등 클라이언트에 적합

• 토큰은 HTTP Header 또는 LocalStorage, SessionStorage 등에 저장하여, 브라우저나 모바일 앱에서 쉽게 사용 가능
• 프론트엔드가 독립된 구조 (SPA, 모바일 앱 등)에서는 세션보다 JWT가 더 편리

5. 보안성 (서명 기반 위변조 방지)

• 토큰은 서버의 secret key로 서명되어 있어, 클라이언트가 내용을 조작해도 서버에서 검증 시 실패
• HMAC, RSA 등의 알고리즘 사용 가능
• ✅ HTTPS는 반드시 필수 (토큰 탈취 방지)