개발자 도구 · JWT 디코더
JWT 분석: 점 분할 및 Base64url 디코딩
· 작동 원리
jwt 인코딩 보안
JWT는 점으로 구분된 세 개의 base64url 세그먼트입니다. 이 게시물은 각 부분을 직접 디코딩하고, 서명 세그먼트가 텍스트가 아닌 이유를 설명하고, 디코더가 알려줄 수 있는 것과 알 수 없는 것을 보여줍니다.
Authorization 헤더의 긴 문자열 — 보고 있는 항목과 정확히 두 개의 점이 있는 이유
Bearer 토큰은 보통 Authorization 헤더에 점으로 구분된 짧은 문자열로 전달됩니다. compact JWS 형식의 일반적인 서명 JWT는 세 세그먼트로 구성되므로 구분점이 두 개입니다. 유효한 토큰은 자격 증명입니다. 프로덕션 토큰을 데모에 붙여넣지 마십시오.
컴팩트 직렬화 — 3개의 base64url 세그먼트로 헤더, 페이로드 및 서명
압축 JWS 직렬화에서 첫 번째 세그먼트는 보호되는 헤더이고, 두 번째 세그먼트는 페이로드이고, 세 번째 세그먼트는 서명 또는 MAC입니다. 서명은 점으로 연결된 인코딩된 처음 두 세그먼트를 포함합니다. 문자열을 분할하면 세그먼트를 찾습니다. 신뢰를 구축할 수 없습니다.
패딩이 없는 Base64url - JWS가 사용하는 알파벳과 세그먼트에 후행 등호가 없는 이유
Base64url은 일반 Base64에서 + 및 / 대신 - 및 _를 사용합니다. 컴팩트 JWS는 후행 = 패딩을 생략합니다. 디코더는 디코딩하기 전에 패딩을 복원할 수 있습니다. 디코딩하면 바이트가 생성됩니다. JSON 헤더 및 클레임의 경우 텍스트를 구문 분석하기 전에 바이트를 UTF-8로 디코딩합니다.
헤더 — 알고리즘 이름과 키 이름을 지정하는 작은 JSON 개체
헤더는 일반적으로 alg를 포함하는 JSON이며 때로는 키 식별자인 kid를 포함합니다. 이는 토큰 자체에 의해 이루어진 주장입니다. 검증자는 자체 허용 알고리즘 정책을 시행하고 적절한 키를 안전하게 획득해야 합니다. alg를 읽는 것만으로는 인증이 되지 않습니다.
페이로드 — 토큰을 보유한 사람은 누구나 읽을 수 있는 JSON 청구 객체입니다.
페이로드에는 sub, exp 및 aud와 같은 클레임이 포함되어 있습니다. 토큰을 보유한 사람은 누구나 읽을 수 있습니다. 인코딩은 암호화가 아닙니다. exp NumericDate는 Unix 시대 이후의 초를 계산하지만 확인되지 않은 주장에는 권한이 없습니다. 읽을 수 있는 페이로드에 비밀을 저장하지 마세요.
서명 - 처음 두 세그먼트에 대한 원시 바이트로, 텍스트로는 의미가 없고 키가 없으면 쓸모가 없습니다.
마지막 세그먼트는 세 번째 JSON 객체가 아니라 base64url로 인코딩된 서명 바이트입니다. 이를 검증하려면 암호화 알고리즘, 키, 애플리케이션 정책이 필요합니다. ToolAcre는 의도적으로 검증을 수행하지 않습니다. 서명 존재 여부를 표시하고 signatureVerified를 항상 false로 표시합니다.
실제 사례 — 나타나는 JSON을 포함하여 세그먼트별로 샘플 토큰 세그먼트를 디코딩합니다.
민감하지 않은 데모 헤더 {"alg":"HS256","typ":"JWT"}와 페이로드 {"sub":"demo"}를 사용합니다. base64url 인코딩은 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 및 eyJzdWIiOiJkZW1vIn0입니다. 디코딩하면 JSON이 복구됩니다. 임의의 세 번째 세그먼트를 추가한다고 해서 토큰이 진짜가 되는 것은 아닙니다.
요약: 디코딩은 신뢰하는 것이 아니라 읽는 것입니다. ToolAcre JWT 디코더는 헤더와 페이로드를 표시하고 서명을 확인하지 않으므로 표시되는 어떤 것도 토큰이 진짜인지 증명할 수 없습니다.
디코딩은 읽는 것이지 신뢰하는 것이 아닙니다. 일회용 토큰의 헤더, 클레임 및 경고에는 ToolAcre JWT 디코더를 사용하세요. 애플리케이션의 신뢰할 수 있는 검증자를 사용하여 서명된 토큰이 유효한지 확인하세요. 표시된 소유권 주장만으로는 액세스 권한을 부여해서는 안 됩니다.