JWT 서명 검증 없이 디코딩하고 클레임 확인하는 방법

JWT 내용을 읽기 전에 구분할 단계

JWT를 읽을 때는 먼저 내용 확인과 서명 검증을 나누어 생각해야 합니다. 이 도구는 텍스트로 받은 토큰을 헤더, 페이로드, 서명 데이터로 나누어 처리합니다. 헤더와 페이로드는 Base64URL로 디코딩한 뒤 UTF-8 JSON으로 해석됩니다. 따라서 토큰 안에 어떤 값이 들어 있는지 살펴보는 용도와 검증을 시도하는 용도를 구분할 수 있습니다.

디코딩 단계에서는 헤더와 페이로드의 구조를 읽습니다. 값이 객체로 해석되면 알고리즘, 토큰 유형, 발급자, 주체, 대상, 시간 관련 클레임처럼 도구가 제공하는 토큰 정보를 확인할 수 있습니다. 세 번째 세그먼트는 서명 데이터로 디코딩되고, 그 세그먼트의 원래 텍스트도 결과에 남을 수 있습니다.

서명 검증은 기본적으로 꺼져 있습니다. 그러므로 디코딩 결과가 표시되었다는 사실만으로 서명이 확인되었다고 해석하면 안 됩니다. 서명의 상태를 살펴보려면 별도로 검증을 요청하고, 그때 사용할 비밀키를 입력해야 합니다. 이 글은 테스트 토큰의 구조와 주요 클레임을 확인한 뒤, 필요한 경우 검증을 요청하는 흐름을 설명합니다.

입력부터 선택적 검증까지 진행하기

확인할 JWT를 텍스트로 준비합니다. 입력란에는 토큰 문자열을 그대로 넣습니다. 값이 비어 있거나 공백만 있으면 성공 결과가 나오지 않으므로, 붙여넣은 뒤 실제 토큰 문자가 있는지 먼저 살펴봅니다. 토큰 전체를 임의로 줄이거나 일부만 복사하면 뒤 단계에서 형식 문제가 생길 수 있습니다.
마침표를 기준으로 세 세그먼트가 있는지 셉니다. 첫 번째는 헤더, 두 번째는 페이로드, 세 번째는 서명에 해당합니다. 세 부분보다 적거나 많으면 지원되는 JWT 형식으로 처리되지 않습니다. 마침표가 값 안에 더 들어갔는지도 함께 확인합니다.
디코딩을 실행합니다. 첫 번째와 두 번째 세그먼트는 Base64URL 디코딩, UTF-8 해석, JSON 해석 순서로 처리됩니다. 세 번째 세그먼트는 서명 데이터로 디코딩되며 원래 문자열이 함께 보일 수도 있습니다. 이 단계의 목적은 토큰 구조와 읽을 수 있는 내용을 확인하는 것입니다.
결과의 헤더를 먼저 봅니다. 객체로 해석된 헤더라면 알고리즘이나 토큰 유형 같은 정보가 표시될 수 있습니다. 이어서 페이로드를 살펴보며 발급자, 주체, 대상, 시간 관련 클레임이 제공되는지 확인합니다. 표시되지 않는 값까지 있다고 가정하지 말고, 실제 결과에 나온 항목만 기록합니다.
서명 검증이 필요한지 판단합니다. 구조만 확인하는 경우에는 기본 설정으로 디코딩 결과를 읽으면 됩니다. 검증을 요청하려면 검증 옵션을 켜고 해당 비밀키를 입력합니다. 도구는 디코딩된 헤더에서 식별한 알고리즘을 기준으로 검증을 시도하며, 결과는 유효 서명 또는 무효 서명과 같은 상태로 보고될 수 있습니다.
검증을 요청한 뒤 결과의 조건을 확인합니다. 비밀키 없이 검증을 요청하면 검증은 건너뛰고 문제가 기록됩니다. 그러므로 검증 상태가 보이지 않는 경우에는 옵션을 켰는지와 비밀키를 입력했는지를 따로 점검해야 합니다. 디코딩만 실행한 결과에는 서명 검증이 수행되었다고 적지 않습니다.

표시된 결과를 단계별로 읽는 법

성공 결과는 토큰의 세 부분을 처리하고 앞의 두 부분을 JSON으로 해석했다는 뜻으로 읽습니다. 헤더와 페이로드가 객체라면 선택된 토큰 정보가 별도로 보일 수 있습니다. 이 정보는 입력된 내용의 확인을 돕지만, 디코딩 자체가 서명의 진위를 판정하는 절차는 아닙니다.

서명 검증을 요청하지 않았다면 서명 상태는 확정되지 않은 상태로 남습니다. 검증을 요청했더라도 비밀키가 없으면 검증이 생략되고 문제가 기록됩니다. 비밀키를 제공한 경우에는 헤더에서 식별한 알고리즘을 기준으로 검증을 시도하며, 보고된 유효 또는 무효 결과를 검증 시도의 결과로 구분해 읽어야 합니다.

첫 번째 또는 두 번째 세그먼트에서 Base64URL, UTF-8, JSON 처리 문제가 생기면 문제가 모이고 전체 결과는 성공하지 않습니다. 비어 있지 않은 세 번째 세그먼트를 디코딩할 수 없어도 문제가 기록됩니다. 반대로 세 번째 세그먼트가 비어 있으면 이 구현에서는 별도의 서명 문제로 추가되지 않을 수 있으므로, 빈 서명 세그먼트의 처리와 유효한 서명 여부를 같은 의미로 보지 않아야 합니다.

결과를 기록할 때는 입력 형식, 헤더 해석 여부, 페이로드 해석 여부, 서명 데이터 처리 여부, 검증 요청 여부를 나누어 적습니다. 이렇게 구분하면 내용이 읽혔다는 사실과 서명이 검증되었다는 사실을 섞지 않을 수 있습니다. 문제가 나타난 경우에는 세그먼트 수와 각 해석 단계의 오류를 순서대로 다시 확인합니다.

사용 예시

개발 중인 서비스의 테스트 JWT 구조를 확인하려고 토큰을 디코딩한 뒤 알고리즘과 발급자 클레임이 표시되는지 살펴봅니다.

세 세그먼트로 구성된 테스트 JWT를 입력하고 서명 검증 옵션을 끈 상태로 실행한 다음, 헤더·페이로드·서명 데이터가 나뉘어 표시되는지 확인합니다.

성공 결과에 해석된 헤더와 페이로드, 처리된 서명 데이터가 포함됩니다. 검증을 요청하지 않았다면 서명 상태는 별도로 확정되지 않습니다.

제한 사항

디코딩 결과만으로 서명의 유효성이나 토큰의 진위를 판단할 수 없습니다. 세그먼트 해석에 문제가 있으면 전체 결과가 성공하지 않을 수 있고, 비밀키 없이 검증을 요청하면 검증이 생략됩니다.

자주 발생하는 오류

빈 값이나 공백만 있는 입력, 또는 마침표로 나눈 세 세그먼트가 아닌 문자열을 붙여넣으면 실패할 수 있습니다. 토큰의 앞뒤와 중간을 임의로 수정하지 말고, 헤더·페이로드·서명에 해당하는 세 부분이 있는지 다시 확인한 뒤 재시도하세요.

자주 묻는 질문

JWT 디코딩에 필요한 입력 형식은 무엇인가요?

입력은 텍스트 JWT여야 하며, 비어 있거나 공백만 있는 값은 성공하지 않습니다. 마침표로 나눈 세 세그먼트가 필요하고, 앞의 두 세그먼트는 Base64URL, UTF-8 JSON 순서로 해석되어야 합니다.

비밀키 없이 JWT 내용을 확인할 수 있나요?

구조와 클레임만 살펴보는 디코딩은 기본적으로 서명 검증 없이 진행됩니다. 검증을 요청할 수는 있지만 비밀키를 제공하지 않으면 검증이 건너뛰어지고 문제가 기록됩니다.

JWT가 디코딩되면 서명도 유효한가요?

디코딩된 헤더와 페이로드가 보인다는 사실만으로 서명이 유효하다고 판단할 수 없습니다. 별도로 검증을 요청하고 비밀키를 제공해야 헤더의 알고리즘을 기준으로 유효 또는 무효 서명 결과를 시도합니다.