JWT란 무엇인가요? JSON Web Token 완벽 가이드

2026-07-25· 태그: what-is-jwt, jwt-authentication, jwt-guide, api-security, token-based-auth

JWT란 무엇인가요?

JSON Web Token(JWT)은 당사자 간에 정보를 JSON 객체로 안전하게 전송하기 위한 간결하고 자체 포함된 방식을 정의하는 개방형 표준(RFC 7519)입니다. JWT는 사용자 인증 및 API 권한 부여부터 마이크로서비스 간 안전한 데이터 교환에 이르기까지 현대 웹 애플리케이션에서 지배적인 토큰 형식입니다.

JWT 인증 작동 방식

JWT 인증은 서버 측 세션 저장소가 필요 없는 무상태(stateless) 패턴을 따릅니다. 이 흐름을 이해하는 것이 JWT가 현대 API 보안의 기본 선택이 된 이유를 이해하는 핵심입니다.

인증 흐름

사용자 로그인 — 클라이언트가 인증 서버에 자격 증명(사용자 이름 및 비밀번호)을 전송합니다.
서버가 JWT 생성 — 서버가 자격 증명을 검증하고, 사용자의 신원과 권한을 포함한 JWT를 생성하여 비밀 키 또는 개인 키로 서명한 후 클라이언트에 반환합니다.
클라이언트가 토큰 저장 — 클라이언트가 일반적으로 localStorage, sessionStorage 또는 HTTP-only 쿠키에 JWT를 저장합니다.
클라이언트가 각 요청에 토큰 포함 — 이후 모든 API 요청에 대해 클라이언트는 Bearer 스킴을 사용하여 Authorization 헤더에 JWT를 포함합니다: Authorization: Bearer <token>.
서버가 토큰 검증 — 서버가 JWT 서명을 검증하고, 만료 시간을 확인하고, 사용자 클레임을 추출하여 요청을 승인합니다.
세션 조회 불필요 — JWT에 필요한 모든 정보가 포함되어 있으므로, 서버는 사용자를 식별하기 위해 데이터베이스나 캐시를 조회할 필요가 없습니다.

이것이 중요한 이유

전통적인 세션 기반 인증은 세션 ID를 서버의 메모리나 데이터베이스에 저장합니다. 인증된 각 요청마다 조회가 필요합니다. JWT는 이 조회를 제거합니다 — 토큰 자체가 사용자의 신원을 증명합니다. 이로 인해 JWT 기반 시스템은 클러스터의 어떤 서버든 공유 세션 상태 없이 토큰을 검증할 수 있으므로 본질적으로 확장성이 뛰어납니다.

JWT vs 세션 기반 인증

| 항목 | JWT 인증 | 세션 기반 인증 | |--------|--------------------|------------------------------| | 저장 위치 | 클라이언트 측 (토큰 내) | 서버 측 (메모리 또는 DB) | | 확장성 | 공유 세션 저장소 불필요 | 인스턴스 간 공유 세션 저장소 필요 | | 도메인 간 | 도메인 간 자연스럽게 작동 | 세션 공유가 어려움 | | 모바일 친화성 | 예 (쿠키 불필요) | 쿠키 지원 필요 | | 취소 | 어려움 (토큰 만료 전까지) | 쉬움 (저장소에서 세션 삭제) | | 페이로드 크기 | 요청당 더 큼 (헤더에 토큰 포함) | 최소 (세션 ID만) |

JWT가 API 보안에 사용되는 이유

JWT를 인증에 적합하게 만드는 특성은 API 보안에도 이상적입니다.

무상태 및 확장성

모든 JWT는 서버가 요청을 승인하는 데 필요한 모든 정보를 포함합니다. 조회할 세션 데이터베이스도, 확인할 캐시도, 서버 간 동기화할 상태도 없습니다. 로드 밸런서는 조정 없이 어떤 서버 인스턴스로든 요청을 라우팅할 수 있습니다.

도메인 간 및 출처 간

JWT는 서로 다른 도메인과 출처 간에 자연스럽게 작동합니다. auth.example.com에서 발급된 토큰을 api.example.com 및 admin.example.com에 액세스하는 데 사용할 수 있습니다. 이는 JWT가 싱글 사인온(SSO) 시스템의 기반이 되는 이유입니다.

세분화된 권한 부여

JWT 페이로드에는 역할, 권한, 조직 멤버십에 대한 사용자 정의 클레임이 포함될 수 있습니다.

{
  "sub": "user_abc123",
  "role": "admin",
  "permissions": ["read:users", "write:users", "delete:users"],
  "org_id": "org_xyz789",
  "iat": 1516239022,
  "exp": 1516325422
}

API 서버는 추가 조회 없이 토큰에서 직접 이러한 클레임을 읽습니다.

싱글 사인온(SSO)을 위한 JWT

싱글 사인온은 가장 일반적인 JWT 사용 사례 중 하나입니다. 일반적인 SSO 아키텍처에서:

사용자가 Auth0, Okta, Keycloak과 같은 ID 공급자(IdP)에 로그인합니다.
IdP가 개인 키로 서명된 JWT를 발급합니다.
사용자가 이 JWT를 여러 애플리케이션에 제시합니다.
각 애플리케이션이 IdP의 공개 키를 사용하여 서명을 검증합니다.
각 애플리케이션이 매 요청마다 IdP와 통신하지 않고 토큰을 신뢰합니다.

이 패턴을 통해 한 번의 로그인으로 이메일, 파일 저장소, 프로젝트 관리, HR 시스템 등 수십 개의 서비스에 액세스할 수 있으며, 각 서비스가 자체 로그인 흐름을 구현할 필요가 없습니다.

JWT 보안 모범 사례

JWT는 API 보안을 위한 강력한 기반을 제공하지만, 올바른 구현이 필수적입니다.

토큰을 짧은 수명으로 유지

액세스 토큰의 exp(만료) 클레임을 15분에서 1시간 사이의 짧은 기간으로 설정하세요. 더 긴 수명의 리프레시 토큰(수일 또는 수주)을 사용하여 사용자가 재인증하지 않고도 새로운 액세스 토큰을 얻을 수 있도록 하세요.

항상 HTTPS 사용

JWT는 페이로드를 암호화하지 않습니다. 토큰을 가로챈 사람은 누구나 디코딩하여 내용을 읽을 수 있습니다. 가로채기를 방지하기 위해 항상 HTTPS를 통해 JWT를 전송하세요.

모든 것을 검증

항상 서명을 검증하고, 토큰이 만료되지 않았는지 확인하고, aud(audience)가 애플리케이션과 일치하는지 확인하고, 예상치 못한 알고리즘의 토큰을 거부하세요.

토큰을 안전하게 저장

클라이언트 측에서는 가능한 경우 HTTP-only 쿠키에, 또는 싱글 페이지 애플리케이션의 경우 메모리에 JWT를 저장하세요. 민감한 데이터에 대한 액세스를 제공하는 토큰은 localStorage에 저장하지 마세요.

흔한 JWT 오해

"JWT는 암호화되어 있다." — 아닙니다. JWT는 암호화된 것이 아니라 서명된 것입니다. 페이로드는 base64url로 인코딩되어 있으며, 이는 되돌릴 수 있습니다. JWE(JSON Web Encryption)는 암호화를 제공하지만, 표준 JWT와는 별개의 사양입니다.

"JWT는 CSRF를 방지한다." — 그 자체로는 아닙니다. Authorization 헤더에 포함된 JWT는 도움이 되지만, 토큰이 쿠키에 있는 경우 CSRF 보호가 여전히 필요합니다.

"JWT는 인증 전용이다." — JWT는 인증뿐만 아니라 권한 부여 데이터 교환, 무상태 세션, 서비스 간 안전한 정보 공유에도 사용됩니다.

온라인으로 JWT 디코딩 및 탐색하기

JWT 디코더 도구를 사용하여 모든 JSON Web Token을 검사하세요. 토큰을 붙여넣고 디코딩된 헤더, 페이로드, 서명 알고리즘을 즉시 확인하세요. 이 도구는 토큰이 어떤 데이터를 담고 있는지 이해하고 올바르게 구조화되었는지 확인하는 데 도움을 줍니다.