JWT 내부에는 무엇이 있나요? 헤더, 페이로드 및 서명(2026)

JWT(JSON 웹 토큰)는 임의의 긴 문자열처럼 보이지만 점으로 연결된 세 개의 데이터 조각일 뿐입니다. 첫 번째 부분에서는 토큰이 어떻게 만들어졌는지 설명합니다. 두 번째 부분은 청구서입니다. 누구를 위한 것인지, 언제 만료되는지, 발급자가 입력한 내용이 무엇인지 등입니다. 세 번째 부분은 신뢰할 수 있는 서버가 확인할 수 있는 서명입니다. 이 가이드는 각 부분, 매일 보게 될 주장, 토큰을 읽는 것과 신뢰하는 것의 차이점을 안내합니다. 실제 토큰을 검사하려면 JWT 디코더에 붙여넣으세요. 브라우저에서 실행되며 값을 업로드하지 않습니다.

점으로 연결된 세 부분

RFC 7519는 압축 JWT를 마침표로 구분된 3개의 Base64URL 세그먼트로 정의합니다. 추가 래퍼도 없고 외부에 JSON도 없으며 일반적으로 패딩 등호도 없습니다. . 마지막 문자열이 비어 있는 경우에도 항상 세 개의 문자열을 얻습니다(보안되지 않은 alg none 형식).

• 헤더: 토큰에 대한 메타데이터이며 거의 항상 alg 및 typ가 포함된 JSON입니다.
• 페이로드: 클레임. 이는 실제로 읽은 데이터 API입니다.
• 서명: 헤더 및 페이로드에 대한 암호화 태그입니다. 이 도구와 이 문서에서는 이를 불투명 바이트로 처리합니다.

JSON을 작성할 수 있는 사람은 누구나 헤더와 페이로드를 생성하고 Base64URL로 인코딩할 수 있습니다. 이것이 처음 두 부분이 공개되는 이유입니다. JWT를 가로채는 사람은 누구나 해당 주장을 읽을 수 있습니다. 기밀 데이터는 다른 형식인 암호화(JWE)하지 않는 한 JWT에 속하지 않습니다.

헤더

헤더는 검증자에게 토큰 처리 방법을 알려줍니다. 작은 JSON 개체입니다. Base64URL 디코딩 후 첫 번째 세그먼트는 일반적으로 다음과 같이 표시됩니다.

• alg - 서명에 사용되는 알고리즘(또는 없음). 공통 값: HS256(공유 비밀이 있는 HMAC), RS256 또는 ES256(비대칭 키).
• typ - 일반적으로 JWT입니다. 일부 발행자는 이를 생략합니다.
• kid - 서버가 JWKS 세트에서 올바른 공개 키를 선택할 수 있도록 하는 선택적 키 ID입니다.
• cty - 드물게 페이로드가 중첩된 JWT인 경우 사용되는 콘텐츠 유형입니다.

위험한 헤더 필드는 alg입니다. 디코더는 토큰이 주장하는 모든 것을 표시합니다. alg none을 존중하거나 공격자가 RS256을 HS256으로 전환하고 마치 HMAC 비밀인 것처럼 공개 키로 서명할 수 있도록 하는 순진한 검증자는 위조된 토큰을 허용합니다. 이는 서버 버그이지 브라우저 디코더로 해결할 수 있는 문제는 아닙니다. alg를 힌트로 읽으십시오. 결코 증거로 읽으십시오.

페이로드(클레임)

페이로드는 또 다른 JSON 객체입니다. JWT 사양은 클레임을 등록된 이름(작은 공유 어휘)과 앱에서 정의하는 비공개 또는 공개 사용자 지정 이름으로 분할합니다. 타임스탬프는 NumericDate 값입니다. 즉, 밀리초가 아니라 1970-01-01 UTC 이후의 초입니다.

자주 보게 될 등록된 주장

• iss - 발행자. 토큰을 발행한 사람(URL 또는 인증 서버 이름)
• 하위 주제. 토큰이 관련된 사용자 또는 서비스입니다.
• aud - 청중. 이를 수락해야 하는 API 또는 앱입니다. 문자열 또는 배열일 수 있습니다.
• exp - 만료. 이 Unix 시간 이후에는 토큰을 거부합니다.
• nbf - 이전에는 아니었어요. 이 Unix 시간 이전에 토큰을 거부하십시오.
• iat - 발행 시간. 발급자가 생성한 시기입니다.
• jti - JWT ID. 토큰을 취소하거나 중복 제거하는 데 사용되는 고유 ID입니다.

맞춤 클레임

다른 모든 것은 이름, 이메일, 역할, 범위, 테넌트 또는 권한 배열과 같은 애플리케이션 데이터입니다. 이러한 필드는 API에 편리하며 디코딩만 하는 경우 위조하기도 쉽습니다. 역할: 디코더에 붙여넣은 토큰의 관리자 클레임은 발급자(또는 공격자)가 해당 문자열을 썼다는 의미입니다. 백엔드가 서명을 확인하고 iss, aud 및 exp를 확인할 때까지는 권한 부여가 아닙니다.

서명

세 번째 세그먼트는 JSON이 아닙니다. HS256의 경우 공유 비밀을 사용하는 ASCII 문자열 header.payload를 통한 HMAC-SHA256입니다. RS256 또는 ES256의 경우 동일한 입력에 대한 비대칭 서명입니다. 디코더는 원시 Base64URL 텍스트를 표시하므로 토큰을 비교할 수 있습니다. 해당 태그를 다시 계산하거나 확인하지 않습니다. 확인에는 비밀 또는 발급자의 공개 키가 필요하며 신뢰할 수 있는 시스템에서 이루어져야 합니다.

일반 Base64가 아닌 Base64URL

JWT 헤더 및 페이로드는 Base64URL(RFC 4648)을 사용합니다. Base64와 동일한 6비트 인코딩이지만 +는 -가 되고 /는 _가 되며 후행 = 패딩이 삭제되는 경우가 많습니다. 이는 쿼리 문자열과 헤더 내에서 토큰을 안전하게 유지합니다. JWT 세그먼트를 일반 Base64 도구에 붙여넣는 경우 먼저 URL 문자를 복원하세요. 그렇지 않으면 JSON이 디코딩되지 않습니다. Base64 인코더/디코더는 일반 Base64용입니다. JWT 도구는 이미 URL 알파벳을 적용합니다.

실제 사례

JWT 문서에 사용되는 클래식 데모 토큰은 작은 헤더와 페이로드로 디코딩됩니다. 점으로 분할하고 처음 두 부분을 Base64URL로 디코딩하면 다음과 같은 결과를 얻을 수 있습니다.

• 헤더 JSON: {"alg":"HS256","typ":"JWT"}
• 페이로드 JSON: {"sub":"1234567890","name":"John Doe","iat":1516239022}
• iat 1516239022는 2018-01-18 01:30:22 UTC입니다. 토큰이 설정된 경우 실제 만료가 몇 년 지난 것입니다.
• 세 번째 세그먼트는 HMAC 서명입니다. 그것을 보면 그 비밀이 정확한지 알 수 없습니다.

Bearer 접두사는 JWT의 일부가 아닙니다. 인증: Bearer eyJ...는 HTTP 헤더 규칙입니다. Strip Bearer와 다음 공간을 찾은 다음 나머지 세 세그먼트를 디코딩합니다. ToolsMinify 디코더가 이를 수행합니다.

읽을 수 있는 내용과 서버가 확인해야 하는 내용

디버깅할 때 디코더를 사용하십시오. 승인할 때 검증기를 사용하세요.

1. alg, typ 및 kid를 읽어서 발급자가 의도한 키를 확인할 수 있습니다.
2. 실패한 요청을 이해하기 위해 하위, 이메일 또는 역할을 읽을 수 있습니다.
3. exp와 iat를 시계와 비교하여 토큰이 오래되었는지 확인할 수 있습니다.
4. 서버는 올바른 키와 올바른 알고리즘으로 서명을 확인해야 합니다.
5. 서버는 iss 또는 aud가 잘못된 토큰과 아직 유효하지 않거나 이미 만료된 토큰을 거부해야 합니다.
6. 서버는 검사가 통과될 때까지 모든 클레임을 신뢰할 수 없는 것으로 처리해야 합니다.

일반적인 실수

• 디코더의 클레임을 신뢰합니다. 누구나 header.payload를 조립하고 정크 서명을 남길 수 있습니다.
• alg none을 수락하거나 토큰이 확인 알고리즘을 선택하도록 허용합니다.
• 페이로드에 비밀번호, 세션 비밀 또는 개인 데이터를 넣습니다. 페이로드는 토큰을 가진 사람이라면 누구나 읽을 수 있습니다.
• 생산 토큰을 임의의 웹사이트에 붙여넣습니다. 토큰이 컴퓨터를 떠나지 않도록 클라이언트 측 디코더를 선호합니다.
• 이 형식을 암호화된 JWT(JWE)와 혼동합니다. 컴팩트 JWE에는 3개가 아닌 5개의 세그먼트가 있습니다.

자주 묻는 질문

JWT는 암호화되어 있나요?

표준 서명 JWT(JWS)는 암호화되지 않습니다. 헤더와 페이로드는 인코딩만 됩니다. 토큰이 있는 사람은 누구나 클레임을 읽을 수 있습니다. 암호화된 토큰은 JWE를 사용하며 모양이 다릅니다. 토큰을 디코더에 붙여넣고 JSON을 볼 수 있다면 이는 기밀이 아닙니다.

디코더가 서명 확인을 거부하는 이유는 무엇입니까?

확인에는 비밀 또는 개인 키 보유자의 공개 키가 필요합니다. 이를 공개 웹페이지로 보내는 것은 안전하지 않으며, 신뢰할 수 없는 사이트에 녹색 "유효" 배지가 표시되면 사람들이 잘못된 수표를 신뢰하도록 교육하게 됩니다. 로컬로 디코딩합니다. API에서 확인하세요.

alg none은 무슨 뜻인가요?

이는 발급자(또는 공격자)가 토큰을 안전하지 않은 것으로 표시했음을 의미합니다. 세 번째 세그먼트는 비어 있습니다. 디코더는 여전히 헤더와 페이로드를 표시할 수 있습니다. 서명되지 않은 토큰을 허용해야 하는 매우 명시적인 로컬 이유가 없는 한 프로덕션 API는 alg none을 거부해야 합니다.

exp와 iat는 밀리초 단위인가요?

아니요. JWT NumericDate 값은 Unix epoch 이후의 초 단위입니다. 클레임이 1.7e12처럼 보이는 경우 실수로 JavaScript Date.now() 밀리초를 보고 있는 것일 수 있습니다.

페이로드를 편집한 후 토큰을 다시 빌드할 수 있나요?

JSON을 Base64URL로 다시 인코딩하고 세 개의 세그먼트를 결합할 수 있지만 이전 서명은 더 이상 일치하지 않습니다. 발급자의 비밀 키나 개인 키가 없으면 새 토큰이 위조됩니다. 그것은 예상됩니다. 디코더는 생산 토큰을 발행하기 위한 것이 아니라 읽기 위한 것입니다.

토큰을 어디에서 안전하게 검사해야 하나요?

브라우저에서 디코딩하고 문자열을 업로드하지 않는 페이지를 사용하세요. ToolsMinify의 JWT 디코더가 이를 수행합니다. 클릭별 연습은 JWT 디코더 사용 방법을 참조하세요.

브라우저에서 토큰 검사

헤더, 페이로드, 서명을 읽을 수 있는 섹션으로 보려면 JWT를 붙여넣으세요. 아무것도 업로드되지 않았습니다:

• JWT 디코더 - 토큰, 예쁜 인쇄 헤더 및 페이로드 JSON을 분할하고 각 부분을 복사합니다.
• JWT 디코더를 사용하는 방법 - 동일한 도구에 대한 단계별 가이드.
• Base64 인코더/디코더 - JWT URL 알파벳이 아닌 일반 Base64입니다.
• 해시 생성기 - 브라우저의 SHA-256 체크섬. JWT 서명이 아닙니다.
• 모든 개발자 도구 - 전체 카테고리 색인.