개발자 도구 · JWT 디코더
디코드와 확인: JWT 서명이 증명하는 것과 디코더가 이를 건너뛰는 이유
· 작동 방식
jwt 보안 암호화
디코딩에는 키가 필요하지 않습니다. 확인하려면 올바른 것이 필요합니다. 이 게시물에서는 서명이 다루는 내용, HMAC와 비대칭 검증의 차이점, 디코딩 전용 도구가 아무 것도 증명하지 못하는 이유를 설명합니다.
잘 디코딩되었으므로 유효해야 합니다. 위조된 토큰을 허용한다는 가정입니다.
공격자가 새 페이로드를 작성하고 임의의 텍스트를 세 번째 세그먼트로 첨부한 후에 토큰을 완벽하게 디코딩할 수 있습니다. Base64url 및 JSON 구문 분석은 공개 변환입니다. 누가 끈을 조립했는지 확인하지도 않습니다. 따라서 “화면에 표시된 청구”는 발행자가 이를 생성했거나 승인했다는 증거가 아닙니다.
ToolAcre는 여러 위치에서 이 경계를 강화합니다. 결과는 항상 `signatureVerified: false`을 전달하고, UI는 출력 옆에 확인되지 않은 클레임 경고를 반복하며, 테스트에서는 `valid` 또는 `verify` 표면이 없다고 주장합니다. 그것은 편의 기능이 누락된 것이 아니라 의도적인 정직함입니다.
서명에 포함되는 내용 — 인코딩된 헤더와 페이로드의 정확한 바이트(점으로 연결됨)
컴팩트 JWS의 경우 서명 입력은 인코딩된 보호 헤더 세그먼트, 리터럴 점 및 인코딩된 페이로드 세그먼트입니다. 확인은 새로 인쇄된 JSON이 아닌 정확한 인코딩된 바이트에 관한 것입니다. 속성을 재정렬하거나 공백을 변경하면 사람이 동일한 객체를 볼 때에도 다른 바이트가 생성될 수 있습니다.
세 번째 세그먼트는 해당 입력을 통해 생성된 인코딩된 서명 또는 MAC 바이트를 전달합니다. ToolAcre는 원시 세그먼트를 보존하고 해당 바이트 길이를 보고할 수 있지만 암호화 검사를 실행하지 않습니다. 데이터 형태를 측정하면 예상된 키가 생성되었거나 처음 두 세그먼트가 변경되지 않은 상태로 유지된다는 사실을 확인할 수 없습니다.
HMAC 대 비대칭 — 확인할 수 있는 사람은 누구나 위조할 수 있는 공유 비밀과 확인만 가능한 공개 키
HMAC를 사용하면 공유 비밀이 MAC 생성 및 확인을 모두 지원합니다. 해당 비밀을 확인할 수 있는 당사자는 다른 토큰을 발행할 수도 있으므로 비밀 배포는 신뢰 경계를 정의합니다. ToolAcre의 메모는 인식된 HS 알고리즘 레이블에 대해 이러한 결과를 명시적으로 나타냅니다.
비대칭 서명은 개인 서명 기능을 공개 검증 자료와 분리합니다. 공개 키를 보유하면 서명 권한을 부여하지 않고도 확인을 지원할 수 있습니다. 이러한 구별은 헤더에서 선언된 비대칭 레이블을 신뢰할 수 있게 만들지 않습니다. 검증자는 어떤 알고리즘과 발급자 키가 허용되는지 이미 알고 있어야 합니다.
키의 출처 — 공유 비밀에 대한 구성, 공개 키에 대한 JWKS 엔드포인트, kid와 일치
공유 비밀은 토큰 텍스트가 아닌 보호된 서비스 구성에서 가져와야 합니다. 공개 확인 키는 신뢰할 수 있는 발급자 관계 및 제어된 키 세트에서 나올 수 있습니다. `kid`은 해당 세트 내에서 선택하는 데 도움이 될 수 있지만 신뢰할 수 없는 임의의 헤더 콘텐츠를 파일, 데이터베이스 또는 네트워크 조회로 변환해서는 안 됩니다.
ToolAcre에는 발급자 구성이 없고 키를 요청하지 않으므로 그곳에서 책임감 있게 검증을 수행하는 것이 불가능합니다. 일반 웹 페이지는 귀하가 신뢰하는 조직, 귀하가 서비스를 제공하는 청중 또는 귀하의 애플리케이션이 허용하는 알고리즘을 추론할 수 없습니다. 이는 디코딩을 통해 검색할 수 있는 속성이 아니라 애플리케이션 정책 입력입니다.
디코딩에 키가 필요하지 않은 이유 - base64url은 암호화가 아닌 인코딩이므로 누구나 주장을 읽을 수 있습니다.
base64url은 암호화가 아닌 가역적 인코딩이므로 디코딩하는 데 키가 필요하지 않습니다. 헤더와 페이로드는 토큰과 함께 이동하도록 되어 있으며 모든 보유자가 복구할 수 있습니다. 이는 유용한 검사를 가능하게 하지만 인코딩된 문자의 시각적 노이즈 뒤에 기밀 정보가 숨겨져서는 안 된다는 의미이기도 합니다.
JSON 구문 분석은 구조만 추가합니다. 이는 `roles`이 배열인지 또는 `exp`가 숫자인지 알려줄 수 있지만 두 값 중 하나가 진짜인지는 알 수 없습니다. ToolAcre는 구조화된 값을 텍스트로, 등록된 설명을 문서로 렌더링하는 동시에 정책을 확인하고 시행할 수 있는 시스템에 권한을 부여합니다.
작동된 예 — 하나의 페이로드 문자가 변경된 토큰은 여전히 완벽하게 디코딩됩니다. 확인 공지만
페이로드가 `{"sub":"demo","role":"reader"}`인 합성 토큰으로 시작합니다. 바이트가 여전히 유효한 JSON을 형성하도록 인코딩된 페이로드 문자 하나를 변경하여 아마도 다른 역할을 생성할 수 있습니다. 두 버전 모두 분할, 디코딩 및 예쁜 인쇄가 가능합니다. 디코드 경로에는 변경된 버전을 거부할 이유가 없습니다.
올바르게 구성된 검증자는 변경된 서명 입력에 대한 암호화 결과를 다시 계산하거나 확인하고 불일치를 거부합니다. 이 비교는 정확한 경계를 보여줍니다. 디코더 성공은 구문을 다루는 반면 검증자 성공은 클레임 정책이 평가되기 전에 신뢰할 수 있는 키 및 허용된 알고리즘을 기준으로 무결성을 설정할 수 있습니다.
여기서 다루지 않는 내용 - ToolAcre JWT 디코더는 설계상 서명을 확인하지 않습니다. 토큰이 진짜임을 증명하는 것은 아무것도 없습니다
ToolAcre는 서명을 확인하지 않습니다. 빈 세그먼트는 경고를 받고, 잘못된 서명 인코딩은 다른 세그먼트를 받고, 측정 가능한 바이트가 있는 것으로 보고되지만 확인되지는 않습니다. 이들 지점 중 어느 곳도 진짜 토큰 판정을 내리지 않습니다. 구현에는 숨겨진 키 획득 또는 알고리즘 실행 경로가 없습니다.
암호화 확인이 성공하더라도 자동으로 작업을 승인하지는 않습니다. 소비 서비스에는 여전히 발급자, 대상자, 시간 및 애플리케이션별 확인이 필요합니다. 지원 및 기본값이 다양하므로 이 문서는 라이브러리 구성 전에 중지됩니다. 서비스에서 사용하는 정확한 검증 도구 및 버전을 문의하세요.
요약: 검사를 위한 디코딩, 신뢰를 위한 검증 — 첫 번째에는 ToolAcre JWT 디코더를 사용하고 두 번째에는 올바른 키가 있는 서버 측 라이브러리를 사용하십시오.
신뢰하기 전에 검사하고 확인하기 위해 디코딩합니다. 헤더 필드, 페이로드 값, 시간 변환 및 구조적 경고를 확인해야 하는 경우 만료된 토큰 또는 합성 토큰용 브라우저 도구를 사용하세요. 읽을 수 있는 출력이 액세스 결정에 직접적으로 영향을 미치지 않도록 하십시오.
독립적으로 제공된 키 자료, 고정된 알고리즘 및 서비스 정책을 사용하여 결과적인 작업을 신뢰할 수 있는 검증자에게 옮깁니다. 해당 경로만 신뢰성과 무결성을 테스트할 수 있으며 후속 클레임 확인을 통해서만 인증을 결정할 수 있습니다. 디코더가 해당 작업을 흐리게 하는 것을 거부하는 것은 보안 기능입니다.