JSON Web Tokens (JWT) 마스터하기: 현대 웹 인증의 핵심

1. 개념 소개

정의

JSON Web Token (JWT)은 웹 환경에서 정보를 안전하게 전송하기 위한 간결하고 자체 포함된(self-contained) 방법입니다. 주로 사용자 인증(Authentication) 및 권한 부여(Authorization)에 사용되며, 토큰 자체에 사용자 정보와 유효성 검증을 위한 디지털 서명이 포함되어 있습니다. 이 서명을 통해 토큰의 내용이 전송 중에 변조되지 않았음을 검증할 수 있습니다.

탄생 배경

전통적인 웹 애플리케이션에서는 사용자가 로그인하면 서버가 사용자의 세션 정보를 저장하고 관리하는 세션 기반 인증 방식을 주로 사용했습니다. 이 방식은 서버 메모리에 사용자 상태를 유지해야 하므로, 특히 사용자 수가 많아지거나 여러 서버로 구성된 분산 시스템, 마이크로서비스 아키텍처 환경에서는 심각한 확장성 문제를 야기했습니다. 세션 정보를 여러 서버 간에 공유하거나 동기화하는 복잡성이 증가하고, 서버에 장애가 발생하면 세션 정보가 유실될 위험도 있었습니다.

JWT는 이러한 문제들을 해결하기 위해 등장했습니다. JWT는 Stateless(무상태성) 방식을 지향합니다. 즉, 서버는 사용자 상태를 저장할 필요 없이, 클라이언트가 보내는 토큰만으로 인증 및 권한을 확인할 수 있습니다. 이는 서버의 부하를 크게 줄이고, 시스템을 수평적으로 확장(Scale Out)하기 용이하게 만들어 현대 웹 서비스의 요구사항에 부합합니다.

왜 중요한가

• 확장성 (Scalability): 서버가 사용자 세션을 관리할 필요가 없으므로, 여러 서버를 자유롭게 추가하고 제거할 수 있습니다. 각 요청은 토큰만으로 처리되므로, 로드 밸런싱 환경에서 특정 서버에 종속되지 않고 어떤 서버에서든 요청을 처리할 수 있습니다.
• 보안 (Security): 토큰이 디지털 서명되어 있어 위변조를 방지합니다. 또한, 토큰 내부에 민감한 정보를 직접 저장하지 않는 한 안전하게 정보를 전달할 수 있습니다. (물론, 토큰 자체가 탈취되면 위험하므로 HTTPS 사용 등 추가 보안 조치가 필수입니다.)
• 크로스 도메인 (Cross-Domain) 및 모바일/SPA 친화적: 여러 서브 도메인이나 다른 도메인 간에도 쉽게 인증 정보를 공유할 수 있습니다. 모바일 앱이나 Single Page Application(SPA)과 같은 클라이언트 측에서 서버와 통신할 때, HTTP 헤더를 통해 토큰을 전달하는 방식이 매우 효율적입니다.
• 표준화된 방식: JWT는 RFC 7519로 표준화되어 있어, 다양한 플랫폼과 언어에서 일관된 방식으로 구현하고 상호 운용할 수 있습니다.

2. 핵심 원리 설명

JWT는 헤더(Header), 페이로드(Payload), 서명(Signature)의 세 부분으로 구성되며, 각 부분은 점(.)으로 구분되어 Base64Url로 인코딩된 문자열 형태입니다. 최종적인 JWT는 header.payload.signature와 같은 형식으로 나타납니다.

헤더 (Header)

토큰의 타입(일반적으로 JWT)과 서명에 사용된 해싱 알고리즘(예: HS256, RS256) 정보를 담고 있습니다.

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

이 JSON 객체는 Base64Url로 인코딩되어 JWT의 첫 번째 부분이 됩니다.

페이로드 (Payload)

클레임(Claim)이라고 불리는 실제 정보들을 담고 있습니다. 클레임은 사용자 ID, 권한, 토큰 만료 시간 등과 같은 엔티티(사용자)에 대한 속성 정보를 의미합니다.

• 등록 클레임 (Registered Claims): 선택적이지만 권장되는 미리 정의된 클레임들입니다. 예를 들어, iss (issuer, 발행자), exp (expiration time, 만료 시간), sub (subject, 주제), aud (audience, 수신자) 등이 있습니다. 특히 exp는 토큰의 유효 기간을 설정하는 데 필수적입니다.
• 공개 클레임 (Public Claims): JWT 사용자가 정의할 수 있는 클레임들입니다. 충돌을 피하기 위해 IANA JWT Registry에 등록되거나 URI 형태로 정의하는 것이 좋습니다.
• 비공개 클레임 (Private Claims): 송신자와 수신자 간에 합의된 정보를 담는 클레임입니다. 예를 들어, 사용자 ID(userId)나 역할(role) 등이 될 수 있습니다.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "exp": 1745678901 // 토큰 만료 시간 (Unix timestamp)
}

이 JSON 객체 또한 Base64Url로 인코딩되어 JWT의 두 번째 부분이 됩니다. 주의할 점은 페이로드 내용은 암호화되지 않고 단지 인코딩만 되므로, 민감한 정보를 직접 담지 않아야 합니다.

서명 (Signature)

토큰의 무결성을 검증하는 데 사용됩니다. 즉, 토큰이 전송 중에 변조되지 않았음을 확인하는 부분입니다. Base64Url(Header) + "." + Base64Url(Payload)를 합친 문자열을, 헤더에 명시된 알고리즘과 서버만이 아는 **비밀 키(Secret