JWT(JSON Web Token)

🔑 1. JWT란?

• JWT (JSON Web Token) = RFC 7519 표준
• 인증·인가 정보(Claims)를 JSON 형식으로 담고, Base64URL 인코딩 + 디지털 서명/암호화로 보호하는 토큰

 

🧱 2. 기본 구조 (3부분)

JWT는 Header.Payload.Signature 구조를 가집니다.

1. Header (헤더)   {
       "alg": "HS256",
       "typ": "JWT"
     }
   • alg: 서명 알고리즘 (예: HS256, RS256, ES256 등)
   • typ: 토큰 유형 (JWT)
2. Payload (페이로드)   {
       "sub": "user123",
       "name": "홍길동",
       "iat": 1695174000,
       "exp": 1695177600,
       "role": "admin"
     }
   • Registered Claims (표준 클레임)
     • iss: 발급자(issuer)
     • sub: 사용자(subject)
     • aud: 대상(audience)
     • exp: 만료(expiration time)
     • nbf: Not Before
     • iat: 발급 시각
     • jti: 토큰 고유 ID
   • Public Claims: 공개 속성 (예: email, role)
   • Private Claims: 발급자·수신자 간 정의된 속성
3.    HMACSHA256(
       base64UrlEncode(header) + "." +
       base64UrlEncode(payload),
       secret
     ) 
   • 대칭키(HMAC) 또는 비대칭키(RSA/ECDSA) 사용
   • 목적: 무결성 보장 (변조 방지)
      
4. Signature (서명)

 

🔄 3. JWT 인증 흐름

1. 사용자가 로그인 요청 → 서버에서 사용자 인증 성공
2. 서버가 JWT 발급 (Access Token, 필요시 Refresh Token)
3. 클라이언트는 토큰을 저장 (쿠키/LocalStorage/SessionStorage)
4. API 요청 시 Authorization: Bearer <JWT> HTTP 헤더에 포함
5. 서버는 서명 검증 & 만료 검증 → 유효하면 요청 처리

 

🔒 4. 보안 고려사항

• 저장 위치
  • LocalStorage → XSS 공격에 취약
  • HttpOnly Secure Cookie 권장
• 만료 시간(exp)
  • Access Token은 짧게 (예: 5~15분)
  • Refresh Token은 길게 (예: 7일~30일)
• 서명 알고리즘 선택
  • HS256(대칭) → 키 유출 위험
  • RS256/ES256(비대칭) → 공개키 검증 구조 → 더 안전
• Replay Attack 방지
  • jti + 서버 측 블랙리스트 사용
• 전송 구간 보호
  • 항상 HTTPS 필수

 

🧩 5. JWT 장단점

✅ 장점

• 상태 비저장(Stateless) → 서버 확장성 좋음
• REST API, 마이크로서비스에 적합
• 클라이언트·서버 간 신뢰 전달 용이

❌ 단점

• 한 번 발급된 토큰은 만료 전까지 강제 무효화 어렵다 (Blacklist 필요)
• Payload가 Base64URL로 단순 인코딩이라 암호화 아님 → 민감정보 저장 금지
• 토큰 길이가 세션 ID보다 큼

 

🛠 6. 실제 예시 (JWT 토큰 문자열)

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkhvbmcgR2lsZG9uZyIsImlhdCI6MTUxNjIzOTAyMn0. TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

• 1️⃣ Header: {"alg":"HS256","typ":"JWT"}
• 2️⃣ Payload: {"sub":"1234567890","name":"Hong Gildong","iat":1516239022}
• 3️⃣ Signature: 비밀키 기반 HMAC-SHA256 결과

 

📌 7. 활용 사례

• OAuth2 / OIDC: Access Token, ID Token
• API Gateway: 클라이언트 인증·인가
• 마이크로서비스 통신: 서비스 간 사용자 컨텍스트 전달
• 서버리스 아키텍처: 인증 상태 공유

👉 정리:
JWT는 JSON 기반, Base64URL 인코딩, 서명 검증 구조로 이루어진 Stateless 인증 토큰이며,
OAuth2, OIDC, API 인증의 사실상 표준으로 자리 잡고 있습니다.

 

 

🔄 JWT 인증 시퀀스 (예상 흐름)

User → Client (앱 또는 웹 UI) → Auth Server → Client → Resource Server

1. 사용자가 로그인 폼에서 사용자 이름 / 비밀번호 전송
2. 클라이언트가 Auth Server(인증 서버)에 인증 요청
3. Auth Server가 사용자 인증 (DB, LDAP 등)
4. 인증이 성공하면 Auth Server가 JWT (Access Token, 보통 만료시간 포함) 발급하고 클라이언트에게 전송
5. 클라이언트는 JWT를 저장 (예: HttpOnly 쿠키 또는 안전한 storage)
6. 이후 클라이언트는 보호된 리소스에 접근할 때 HTTP 요청 헤더(Authorization: Bearer <JWT>)에 토큰 포함
7. Resource Server가 JWT의 유효성 (서명, 만료시간, issuer, audience 등) 검증
8. 유효하면 요청 처리 및 응답 반환; 무효면 오류 (401 Unauthorized) 반환

🔍 확장 흐름: Refresh Token 포함 시나리오

• 초기 로그인 시 Access Token (짧은 유효기간) + Refresh Token (긴 유효기간) 같이 발급
• Access Token 만료 시 클라이언트는 Refresh Token을 사용해 Auth Server에 새로운 Access Token 요청
• Auth Server가 Refresh Token 유효 확인 → 새 JWT 발급
• 클라이언트 새 토큰을 받아 사용