GLOSSARY

JWT (JSON Web Token)

중급

이 페이지는 AI 문맥에서 자주 쓰이는 JWT (JSON Web Token)의 뜻과 쓰임을 중급 난이도 기준으로 정리한 AI 용어사전 항목입니다. 정의와 맥락, 관련 용어 5개 순서로 묶었으니, 아래 설명을 먼저 읽고 연결된 개념과 글까지 이어서 보면 이해가 빨라집니다.

JWT(JSON Web Token)는 주체에 관한 주장 정보를 JSON으로 표현해 당사자 사이에 전달하는 토큰 형식입니다. 내용을 해독하는 것과 신뢰성을 검증하는 것은 다릅니다. 서명 또는 암호화 방식과 수신 측의 검증 규칙에 따라 사용하며, 인증 서비스 자체와는 구분됩니다. 발급자와 대상, 만료 같은 필드를 담을 수 있지만 필요한 필드는 적용 규약이 정합니다.

JSON 주장 정보를 담는 형식

JWT를 정의한 RFC 7519는 토큰에 담는 정보 항목을 클레임(claim)이라고 부릅니다. 발급자를 나타내는 iss, 주체를 나타내는 sub, 대상을 나타내는 aud 같은 이름을 정의합니다. 애플리케이션은 이 값을 읽어 누가 무엇에 관해 발급한 토큰인지 판단합니다. 어떤 클레임을 필수로 넣을지는 JWT를 사용하는 애플리케이션 규약이 정합니다.

만료 시점을 나타내는 exp와 사용 가능 시작 시점을 나타내는 nbf, 발급 시점을 나타내는 iat도 서로 다른 역할입니다. 값이 숫자로 표현되더라도 각 필드가 답하는 질문은 다릅니다. 발급된 때를 알고 있는 것과 아직 사용할 수 있는 토큰인지 확인한 것은 같은 검증이 아닙니다. 수신자는 사용하는 규약에 맞춰 필요한 시간 조건을 적용합니다.

JWT는 형식이며 사용 목적은 적용하는 프로토콜이 정합니다. 로그인 뒤 API 요청에 전달하는 용도로 쓸 수 있지만, JWT라는 이름만으로 사용자 로그인 과정이나 권한 부여 정책이 모두 정해지지는 않습니다. 어느 발급자를 신뢰하고 어떤 요청에 사용할지 정한 서비스의 규칙이 함께 필요합니다. 토큰 안에 적힌 역할 이름을 읽는 일과 그 역할을 믿어도 되는지 판단하는 일도 구분됩니다.

서명과 암호화의 보호 범위

RFC 7519의 표현 규정은 JSON 주장을 JWS의 페이로드나 JWE의 평문으로 표현하는 방식을 설명합니다. 흔히 접하는 서명형 JWT는 점으로 구분된 문자열을 사용하지만, JWT 전체를 항상 동일한 개수의 조각으로만 정의하면 암호화형 표현을 놓칩니다. 실제 형식과 처리 방법은 사용하는 보호 방식에 따라 달라집니다. 받은 문자열의 모양만 확인하는 것으로 검증이 끝나지 않습니다.

서명형 토큰의 내용을 Base64url 방식으로 해독해 읽는 작업은 서명 검증과 다릅니다. 서명은 발급 주체와 데이터 변경 여부를 확인하는 데 사용하고, 암호화는 내용을 읽을 수 있는 범위를 제한하는 역할을 합니다. 읽을 수 있는 내용에 비밀이 들어 있으면 서명이 붙어 있어도 그 내용을 숨기지는 못합니다. 토큰에 어떤 정보를 넣을지는 전달 경로와 보호 방식에 맞춰 결정합니다.

토큰을 읽는 도구가 값을 화면에 보여 줬다는 사실은 그 값이 진짜라는 증거가 아닙니다. 검증되지 않은 토큰도 JSON 모양으로 해석될 수 있습니다. 개발 과정에서 페이로드를 보는 기능과 서비스가 요청을 받아들일지 결정하는 기능을 분리하면, 디버깅 화면의 결과를 인증 성공으로 오해하는 일을 줄일 수 있습니다. 로그에는 필요한 식별 정보와 검증 결과를 남기는 방식이 적합합니다.

수신자가 적용하는 검증 조건

JWT 보안 권고인 RFC 8725는 사용 가능한 알고리즘을 호출자가 지정하고, 지정하지 않은 알고리즘을 암호 연산에 사용하지 않도록 요구합니다. 토큰의 alg 이름을 보고 아무 알고리즘이나 받아들이는 방식과 다릅니다. 서비스가 허용한 알고리즘과 키의 사용 규칙을 함께 적용해야 어떤 발급 결과를 신뢰하는지가 명확해집니다.

같은 권고는 발급자와 대상 검증, 서로 다른 용도의 JWT를 혼동하지 않는 규칙도 다룹니다. 서명이 맞더라도 다른 서비스를 위해 발급한 토큰이라면 요청한 API에 쓸 수 있는지 별도로 판단합니다. 같은 조직에서 발급한 모든 토큰을 모든 서비스가 받아들이는 방식은 용도별 경계를 잃게 됩니다. 토큰 형식의 유효성과 현재 요청의 이용 자격은 단계가 다릅니다.

만료된 토큰, 잘못된 대상, 알 수 없는 키는 각각 구별할 수 있는 실패 조건입니다. 운영 기록에 검증 단계와 실패 유형을 남기면 사용자 입력 문제와 발급 설정 문제를 나누기 쉽습니다. 실제 구현에서는 사용하는 라이브러리와 적용 프로토콜의 추가 요구도 함께 확인합니다.

RELATED TERMS