JWT의 클레임 형식과 직렬화 종류

JSON Web Token(JWT, RFC 7519)은 당사자 사이에 클레임을 표현하는 컴팩트한 형식입니다. JSON 데이터를 Base64URL로 표현하는 것은 암호화가 아니며, 서명된 JWS의 페이로드는 별도 암호화가 없으면 읽을 수 있습니다. 기밀성이 필요하면 JWE를 검토해야 합니다. JWT가 곧 인증 방식이나 무상태 세션을 뜻하는 것도 아닙니다. 어떤 클레임을 신뢰할지와 검증 절차는 이를 사용하는 프로토콜과 애플리케이션이 정합니다.

흔히 보는 세 부분 header.payload.signature는 JWS Compact Serialization입니다. JWT는 서명된 JWS, 암호화된 JWE 또는 제한적으로 비보호 표현일 수 있어 모든 JWT가 세 부분인 것은 아닙니다. iss, sub, aud, exp, nbf, iat, jti는 등록 클레임 이름이며 RFC 7519가 모두 매 토큰에 필수로 요구하지 않습니다. 서명은 검증에 성공하고 예상 키·알고리즘과 맞을 때 변경 여부와 발급 키 보유를 확인하는 데 쓰입니다.

전문가 관점: 서명 검증과 세션 정책은 별개

IETF RFC 8725는 Yaron Sheffer, David Hardt, Michael Jones 등 저자가 참여한 JWT 보안 모범 관행 문서로, 검증기가 허용 알고리즘을 고정하고 발급자·대상자 등 애플리케이션 문맥을 확인하도록 안내합니다. Auth0의 Principal Security Engineer Maria Vasilevskaya는 2025년 글에서 자체완결형 액세스 토큰의 회수 지연을 설명하면서, 짧은 만료시간뿐 아니라 백채널 로그아웃·송신자 제약 같은 통제도 다룹니다. 이는 특정 ID 제공자의 설계 사례이며 모든 JWT 시스템에 같은 기능이 있는 것은 아닙니다.

토큰 형식만으로 인증·암호화·무상태성이 정해지지 않음

JWT는 클레임을 표현하는 형식입니다. 서명된 JWS의 페이로드는 기본적으로 Base64URL 인코딩일 뿐 비밀이 아니며, 암호화가 필요하면 JWE 같은 별도 보호 형식을 사용해야 합니다. JWT에는 서명·암호화·비보호 형태가 있으며, 세 점으로 나뉜 3부분 표현은 일반적인 JWS Compact Serialization에 해당하지 모든 JWT에 해당하지 않습니다. 등록 클레임도 모두 필수인 것은 아닙니다. 서명 검증 성공만으로는 사용자 인증·권한 부여가 끝나지 않습니다. 알고리즘, 키 용도, 서명, issuer, audience, 만료·활성 시점 및 앱 권한을 검증하고, 즉시 회수가 필요하면 서버측 세션 상태나 denylist 등의 비용을 설계에 포함하세요.

참고 문헌 및 자료 출처