RFC 7519 · JSON Web Signature

JWT 소개

JSON Web Token(JWT)은 클레임을 간결하고 URL에 안전한 문자열로 표현하는 개방 표준(RFC 7519)입니다. OAuth 2.0·OpenID Connect에서 널리 쓰이지만 형식 자체는 범용이며, 올바른 검증 자료를 가진 당사자는 서명을 확인하고 클레임을 해석할 수 있습니다(키·시계 관리 한도 내).

이 페이지에서는 JWT가 어떻게 만들어지는지, 각 부분을 어떻게 읽는지, 토큰만으로 기대할 수 있는 보장과 그렇지 않은 것을 설명합니다.

header.payload.signature

간결한 형태: 점으로 구분된 세 개의 Base64URL 세그먼트.

간결한 직렬화와 인코딩

일반적인 형태(JSON Web Signature, JWS)에서 JWT는 점으로 구분된 세 세그먼트(헤더·페이로드·서명)입니다. 앞의 두 세그먼트는 JSON을 Base64URL로 인코딩한 것(표준 Base64가 아님)으로, 패딩 생략·URL 안전 문자로 헤더와 쿼리 문자열에 실을 수 있습니다.

Base64URL은 암호화가 아닙니다. 헤더와 페이로드는 문자열을 가진 누구나 읽을 수 있습니다. 서명은 서명 키를 통제하는 당이 앞의 두 세그먼트를 만들었다는 것을 보여 주며 내용을 숨기지는 않습니다.

JWT 구조

간결한 JWS 형태에서 각 세그먼트의 역할은 다음과 같습니다.

페이로드

클레임을 담은 JSON 객체: 주체, 유효 기간, 대상, 애플리케이션 전용 필드. 발급자가 정의하면 중첩 객체도 허용됩니다.

서명

"header.payload" 바이트(두 인코딩 세그먼트와 그 사이의 점)에 대한 암호 값으로, 헤더의 알고리즘과 공유 비밀(HMAC) 또는 비대칭 개인 키(RSA, ECDSA, EdDSA)를 사용합니다.

클레임: 페이로드 안의 내용

클레임은 이름/값 쌍입니다. 의미는 맥락에 달리지만 RFC 7519는 등록된 이름을 정의해 라이브러리와 API가 일관되게 해석하도록 합니다.

등록된 클레임

예: iss, sub, aud, exp, nbf, iat, jti. exp와 nbf는 Unix 시각입니다. 올바르게 검증하려면 검증자에게 신뢰할 수 있는 시계가 필요합니다.

공개 클레임

IANA "JSON Web Token Claims" 레지스트리에 등록하면 많은 구현 간 상호 운용이 쉬워지지만, 생산자와 소비자가 의미에 합의하기 전까지는 관례에 불과합니다.

비공개 클레임

발급자와 소비자가 합의한 이름(내부 역할·테넌트 ID 등). 등록 이름과 충돌하지 않도록 하거나 양쪽을 모두 통제할 때만 사용하세요.

알고리즘 한눈에 보기

헤더의 alg 값이 서명 계산 방식을 고릅니다. 모델을 잘못 고르면 누가 검증할 수 있는지·비밀을 어떻게 공유할지에 영향을 줍니다.

HMAC(HS*): 하나의 공유 비밀로 서명과 검증. 단일 서비스에는 단순하지만 모든 검증자가 비밀을 보유해야 합니다.
RSA 또는 ECDSA/EdDSA: 발급자가 개인 키로 서명하고 검증자는 공개 키 사용(종종 JWKS). 마이크로서비스와 서명 비밀을 가져선 안 되는 공개 클라이언트에 적합합니다.
"none" 알고리즘은 프로덕션에서 받아들이면 안 됩니다. 잘못 구성하면 서명 없는 토큰을 허용할 수 있습니다. 알 수 없거나 비활성화된 알고리즘은 명시적으로 거부하세요.

보안: 신뢰·프라이버시·검증

유효한 서명은 서명 키를 통제하는 당이 발급했고 헤더와 페이로드가 변조되지 않았음을 보여 줍니다. 그 자체로 암호화는 아닙니다.

페이로드에 비밀번호·API 키·장수명 비밀을 넣지 마세요. 서명 외 기밀성이 필요하면 전송은 TLS, 형식은 JWE 등 별도 흐름을 고려하세요.

서버는 예상 키나 JWKS로 서명을 검증하고 exp(보통 nbf도)를 확인하며, 아키텍처가 의존하면 aud와 iss를 강제하고, 짧은 수명과 리프레시를 적절히 사용해야 합니다.

흔한 사용 사례

JWT는 다음과 같이 자주 사용됩니다:

인증된 신원과 권한 결정 표현(베어러 액세스 토큰, OpenID Connect ID 토큰)
분산 시스템에서 서비스 간 신원·위임 전파
안전한 저장소와 리프레시 전략과 함께 클라이언트 세션 상태 모델링
API 게이트웨이·리소스 서버에 OAuth 2.0 스코프나 사용자 정의 클레임 운반

실무적 한계

JWT 설계 시 유의할 제약:

크기: 토큰은 종종 HTTP 헤더에 실립니다. 큰 페이로드는 지연을 늘리고 프록시 한도에 걸릴 수 있습니다.
폐기: 순수 무상태 JWT는 추가 인프라(거부 목록, 인트로스펙션, 매우 짧은 수명) 없이 즉시 폐기할 수 없습니다.
시계 편차: exp·nbf 검증은 발급자와 검증자 시각이 대략 동기화되어 있다고 가정합니다.