개발자 도구 · JWT 디코더
Base64 및 Base64url: 표준 Base64 디코더에서 JWT이 실패하는 이유
· 작동 방식
jwt 베이스64 인코딩
JWT 세그먼트를 일반 base64 디코더에 붙여넣으면 문자나 패딩에 대해 문제가 발생할 수 있습니다. 이 게시물에서는 base64url 변형 JWS 규정과 둘 사이를 변환하는 방법을 설명합니다.
잘못된 문자, 잘못된 패딩 — base64가 base64url을 만날 때 나타나는 오류
"잘못된 문자" 또는 "잘못된 패딩" 메시지는 보통 JWT 세그먼트가 일반 Base64를 예상하는 디코더에 제공되었음을 의미합니다. 토큰이 올바르게 복사될 수 있습니다. 그 표현은 base64url 규칙을 따르는 반면, 수신 유틸리티는 관련은 있지만 동일하지 않은 알파벳을 허용하거나 명시적인 패딩을 요구합니다.
ToolAcre는 헤더와 페이로드의 불일치를 방지합니다. 바이트 디코더는 공백을 제거하고, URL 안전 기호를 변환하고, 길이가 허용하는 경우 생략된 패딩을 복원한 다음 바이트를 엄격한 UTF-8로 변환합니다. 어떤 단계에서든 실패하면 원시 브라우저 예외가 아닌 INVALID_JWT 오류가 됩니다.
두 개의 알파벳 - 더하기 및 슬래시 대 하이픈 및 밑줄, 그리고 URL이 강제로 변경된 이유
표준 Base64는 마지막 두 알파벳 위치에 더하기 및 슬래시를 사용합니다. Base64url은 동일한 위치에 하이픈과 밑줄을 할당합니다. 기본 6비트 값은 변경되지 않으므로 `-`을 `+`로, `_`를 `/`로 변환하면 디코딩된 모든 바이트가 보존됩니다. Transport-Safe 철자만 변경됩니다.
이러한 대체 항목은 더하기 또는 슬래시에 이미 구문이 있는 채널에서 중요합니다. URL 안전 철자를 사용하면 양식이나 경로 처리 시 실수로 해석되는 일이 줄어듭니다. 비밀성, 무결성 또는 신뢰성을 추가하지 않습니다. 세그먼트를 받은 사람은 누구나 대체를 취소하고 암호화 키 없이 동일한 바이트를 복구할 수 있습니다.
패딩 — JWS가 등호를 제거하는 이유와 엄격한 디코더를 위해 등호를 복원하는 방법
ToolAcre는 생략된 패딩을 허용합니다. 알파벳 정규화 후 세그먼트 길이를 모듈로 4로 검사합니다. 나머지 2개에는 등호 2개가 필요하고, 나머지 3개에는 1개가 필요합니다. 나머지 하나는 완전한 Base64 값이 불가능하며 모양이 추측되지 않고 잘린 문자열로 거부됩니다.
패딩 복구는 토큰 복구가 아닌 기계적 프레이밍입니다. 등호를 추가해도 복사 중에 손실된 문자를 복원할 수 없으며 성공적인 바이트 디코딩은 해당 바이트가 발급자로부터 왔다는 것을 표시하지 않습니다. 구현에서는 `atob`을 호출하기 전에 브라우저 디코더에 필요한 표준 길이를 재구성할 뿐입니다.
전체 토큰을 한 번에 디코딩 — 점을 먼저 분할하지 않는 실수
압축 서명 토큰은 세그먼트가 디코딩되기 전에 점으로 분할되어야 합니다. `header.payload.signature`을 Base64 함수에 전달하면 Base64 알파벳이 아닌 JWT 직렬화에 속하는 점이 도입됩니다. ToolAcre는 이 JWS 모양의 입력에 대해 정확히 3개의 세그먼트가 필요하며 해당 구조가 없을 때 관찰된 개수를 보고합니다.
암호화된 컴팩트 직렬화는 동일한 객체가 아니기 때문에 5부분으로 구성된 케이스는 별도의 JWE 메시지를 받습니다. 대신 두 개 또는 네 개의 부분이 잘림이나 잘못된 입력을 제안합니다. 이 구조적 검사는 JSON 해석 이전에 이루어지며 잘못된 형식의 인코딩된 텍스트 또는 잘못된 형식의 JSON과 구별되는 복사 오류를 유지합니다.
작업된 예 — 하나의 세그먼트를 base64url에서 base64로 변환하고 패딩한 후 JSON로 디코딩
제대로 변환하려면 `eyJhbGciOiJIUzI1NiJ9`을(를) 사용하세요. 변형마다 다른 알파벳 문자가 포함되어 있지 않지만 누락된 패딩은 여전히 파이프라인을 보여줍니다. 그 길이는 패딩 복원을 허용합니다. 디코딩은 `{"alg":"HS256"}`에 대해 UTF-8 바이트를 생성하고 JSON 구문 분석은 하나의 `alg` 속성이 있는 객체를 생성합니다.
하이픈이나 밑줄이 포함된 세그먼트는 두 개의 기호가 먼저 대체되는 동일한 순서를 따릅니다. ToolAcre는 `base64ToBytes` 내에서 이러한 작업을 수행한 다음 `decodeSegment`이 결과 텍스트를 구문 분석합니다. 표시되는 알고리즘은 확인되지 않은 헤더가 선언하는 것입니다. 검증 정책으로 선택되지 않았습니다.
클레임의 유니코드 — 이름을 올바르게 표시하려면 디코딩된 바이트를 UTF-8로 읽어야 하는 이유
주장에는 악센트, CJK 문자 또는 이모티콘이 포함될 수 있습니다. Base64는 바이트에서 작동하므로 디코딩된 각 바이트를 독립 문자로 처리하면 멀티바이트 텍스트가 손상됩니다. 올바른 경로는 기호를 바이트로 인코딩한 다음 UTF-8 디코더입니다. ToolAcre는 치명적 모드로 `TextDecoder`을 구성하므로 유효하지 않은 UTF-8는 크게 실패합니다.
테스트는 `Zoë 世界 🙂`을 포함하는 페이로드를 다루고 디코딩 후 정확한 문자열을 예상합니다. 그 결과는 바이트-텍스트 파이프라인이 이 테스트 값을 유지했음을 증명합니다. 페이로드에 이름이 지정된 사람이 존재하는지, 발급자가 청구를 승인했는지 또는 토큰이 변경되었는지 여부에 대해서는 여전히 아무 것도 알려주지 않습니다.
여기서 다루지 않는 내용 — 텍스트가 아닌 바이트로 디코딩되고 무엇이든 의미하려면 키가 필요한 서명 세그먼트
서명 세그먼트가 JSON 경로 외부에 있습니다. ToolAcre는 원래 인코딩된 형식을 유지하고 디코딩된 바이트 길이만 측정하려고 시도합니다. 잘못된 서명 Base64는 경고를 생성하지만 헤더 및 페이로드 검사를 방지하지는 않습니다. 빈 세 번째 세그먼트는 서명 바이트가 없다는 다른 경고를 생성합니다.
두 결과 모두 확인 결과가 아닙니다. 의미 있는 서명 검증에는 신뢰할 수 있는 키 자료, 공격자가 제어하는 입력과 독립적으로 선택된 허용 알고리즘 및 애플리케이션 검사가 필요합니다. 바이트 수는 모양을 진단할 때 유용하지만 0 또는 32개의 측정된 바이트는 요청을 승인하거나 발급자를 설정할 수 없습니다.
요점: base64url을 말하는 디코더를 사용하십시오. ToolAcre JWT 디코더는 헤더와 페이로드에 대한 알파벳과 패딩을 처리합니다.
즉각적인 작업이 JSON을 검사할 때 base64url을 이해하는 디코더를 사용하십시오. ToolAcre는 처음 두 세그먼트에 대해 알파벳, 생략된 패딩, 엄격한 UTF-8 및 객체 전용 JSON을 처리합니다. 또한 불가능한 길이를 거부하고 헤더 또는 페이로드 실패 여부를 식별하는 메시지에 구문 분석 실패를 래핑합니다.
해당 경계에서 정지하세요. 클린 디코드는 문자열에 복구 가능한 바이트와 적합한 JSON 개체가 있음을 의미합니다. 이는 해당 주장이 신뢰할 수 있거나, 인증되었거나, 승인되었거나, 수정되지 않았다는 것을 의미하지 않습니다. 별도로 구성된 검증자만이 이러한 질문에 답할 수 있으며, 이 브라우저 도구는 의도적으로 검증 작업을 노출하지 않습니다.