JWT(Json Web Token)에 대해 정리

엔터프라이즈급 개발에서 자주 쓰이는 인증/인가 방식

🔑 JWT (Json Web Token)

1. 개념

• JWT는 JSON 형식으로 정보를 안전하게 주고받기 위한 토큰(Token) 기반 인증 방식입니다.
• 서버와 클라이언트가 인증된 사용자인지를 확인하기 위해 사용되며, Stateless(무상태) 특성을 가집니다.
• 기본적으로 Header.Payload.Signature 3부분으로 구성됩니다.

2. 구조

📌 1) Header (헤더)

• 토큰 타입과 서명 알고리즘을 지정합니다.

{
  "alg": "HS256",
  "typ": "JWT"
}

📌 2) Payload (페이로드)

• 실제 담고 싶은 데이터(클레임, Claims)를 포함합니다.
• 등록된(Reserved), 공개(Public), 비공개(Private) 클레임으로 나뉩니다.

{
  "sub": "user123",        // Subject (사용자 ID 등)
  "name": "솔개",
  "role": "ADMIN",         
  "exp": 1734943200        // 만료 시간 (UNIX TIME)
}

📌 3) Signature (서명)

• Header와 Payload를 Base64URL로 인코딩한 뒤, 비밀키(Secret)로 서명한 값.
• 토큰 위변조 여부를 확인할 수 있음.

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

3. 특징

✅ Stateless

• 서버는 세션을 저장하지 않고, 요청 시 전달된 JWT만 검증.
• 서버 확장성(Scalability)에 유리.

✅ Self-contained

• JWT 자체에 사용자 인증 및 권한 정보 포함.

✅ 확장성

• OAuth2.0, OpenID Connect와 함께 자주 사용.

4. 장점과 단점

✅ 장점

• 세션 저장 필요 없음 → 서버 부하 감소.
• 여러 서비스 간 인증 정보 공유 쉬움 (Single Sign-On, SSO).
• 클라이언트-서버 간 데이터 교환 표준화.

❌ 단점

• 토큰이 커질 수 있음 (많은 Claim 포함 시).
• 발급 후 강제 만료시키기 어려움 (→ Redis 블랙리스트 활용 필요).
• 탈취당하면 만료 전까지는 악용 가능.

5. JWT 인증 흐름

1. 클라이언트가 로그인 요청 (ID/PW).
2. 서버가 유효성 검증 후 JWT 생성 → 클라이언트에 전달.
3. 클라이언트는 이후 요청마다 HTTP Header에 JWT 포함 (Authorization: Bearer ).
4. 서버는 JWT 서명 검증 후 접근 허용.

6. 실무 적용 시 고려사항

• Access Token + Refresh Token 전략

  • Access Token은 짧게(15분~1시간).
  • Refresh Token은 길게(2주~1달).

• 토큰 보관 위치

  • LocalStorage(XSS에 취약), HttpOnly Cookie(보안 강화).

• 로그아웃 처리

  • Redis에 블랙리스트 저장 → 만료 전 강제 무효화.

• HTTPS 필수

  • 평문 전송 시 탈취 위험.

📌 요약
JWT는 "Stateless 인증 방식" 으로, 서버 확장성이 필요하거나 마이크로서비스, 모바일/웹 통합 인증 등에 최적화된 방식입니다.
단, 만료 관리와 보안 이슈 때문에 Refresh Token, 블랙리스트, HTTPS 같은 보완 장치가 반드시 필요합니다.