개발자 도구 · Base64 인코더 및 디코더
Base64 대 base64url: 표준 디코더가 거부하는 이유 - 및 _
· 작동 방식
베이스64 인코딩 개발자 워크플로
base64url은 +와 /를 -와 _로 교체하므로 출력이 이스케이프 없이 URL과 파일 이름으로 이동할 수 있습니다. 이 게시물에서는 두 알파벳, 두 알파벳 사이를 변환하는 방법 및 패딩이 일반적으로 삭제되는 이유에 대해 설명합니다.
코드를 제외한 모든 곳에서 디코딩하는 토큰 — 단일 - 또는 _로 인해 발생하는 잘못된 문자 오류
JWT 세그먼트가 잘못된 문자 오류 명명 대시로 인해 표준 Base64 디코더에서 디코딩되지 않습니다. 그러나 시각적으로 대시는 나타나지 않습니다. 다시 보세요. 그렇습니다. base64url 버전은 표준 Base64가 +를 사용하는 경우 -를 사용하고 /.을 사용하는 경우 _를 사용합니다. 많은 디코더는 하나의 알파벳만 허용하며 URL 안전을 위해 인코딩된 토큰은 RFC 4648 표준 Base64를 기대하는 코드에 의해 거부됩니다.
두 알파벳은 동일합니다. 그들 사이의 변환은 기계적 문자 교체입니다. 문제는 URL에서 +와 /가 의미를 갖기 때문에 발생합니다. 더하기 기호는 application/x-www-form-urlencoded 양식 데이터의 공간을 나타냅니다. 슬래시는 URL의 경로 구분 기호입니다. 백분율 인코딩 없이 Base64를 URL 쿼리 매개변수에 직접 포함하는 경우 + 및 /, 디코더가 이를 잘못 해석할 수 있습니다.
+ 및 /가 URL과 파일 이름에서 문제가 되는 이유 — 경로에서 /의 예약된 의미와 양식 데이터에서 공백인 +의 의미
A +는 디코더에 도달하기 전에 공백으로 읽을 수 있습니다. /는 매개변수 값을 잘못된 위치에서 분할할 수 있습니다. RFC 4648 섹션 5은 모호성을 제거하기 위해 base64url 알파벳을 정의합니다. + 대신 -를 사용하고 /, 대신 _를 사용하면 URL 및 파일 이름에서 출력이 안전합니다. 두 알파벳은 두 문자를 제외하고는 동일합니다.
표준 Base64는 62 및 63 위치의 문자를 사용합니다: A–Z(0–25), a–z(26–51), 0–9 (52–61), + (62), / (63). base64url은 A–Z(0–25), a–z(26–51), 0–9(52–61)를 사용합니다. - (62), _ (63). 비트 재그룹화, 패딩 규칙, 비트를 인덱스에 매핑하는 등 다른 모든 것은 동일합니다. 표준 Base64에 대한 색인 문자열은 base64url에 대한 색인 문자열을 생성합니다. 62 및 63 위치의 문자만 다릅니다.
RFC의 base64url 알파벳 4648 섹션 5 — 대체된 두 문자 및 다른 변경 사항이 없는 이유
입력에 62 또는 63 색인이 포함되어 있지 않은 경우(표준에는 + 또는 /가 없고 base64url에는 - 또는 _가 없음) 두 알파벳 모두 동일한 출력을 생성합니다. 표준 Base64를 base64url로 변환하는 것은 찾기 및 바꾸기가 간단합니다. -를 +로 바꾸고 _를 /로 바꿉니다. 표준 Base64에서 base64url 문자열을 디코딩하려면 역방향이 필요합니다. /.의 경우 + 및 _를 교체해야 합니다.
변환은 대칭이며 항상 유효합니다. 잘못된 문자 오류 이름 지정(또는 _)으로 인해 디코딩에 실패한 토큰이 발견되면 디코더가 base64url을 허용하는지 확인하세요. 그렇지 않은 경우 문자 대체를 적용하고 입력이 올바른 형식이면 디코딩이 성공합니다. base64url로 인코딩된 JWT 헤더 {"alg":"HS256","typ":"JWT"}를 고려하세요. 표준 UTF-8 바이트는 비트 재그룹화를 거칩니다. 3바이트는 4개의 인덱스가 되며 base64url 알파벳으로 조회됩니다. ToolAcre는 패딩을 알파벳 토글에 묶는 대신 인코더 선택으로 노출합니다. 이러한 분리는 유용한 증거입니다. URL 안전 출력은 패딩되거나 패딩되지 않을 수 있지만 디코더는 브라우저 기본 요소를 호출하기 전에 두 형식 중 하나를 정규화합니다. 알파벳과 패딩은 하나의 스위치가 아닌 관련 규칙입니다.
base64url의 패딩은 관례에 따라 선택 사항입니다. JWT가 =를 생략하는 이유와 디코더가 길이에서 이를 복원할 수 있는 방법
인덱스가 62인 경우 출력 문자는 -입니다. 63인 경우 출력은 _입니다. 표준 알파벳을 통해 동일한 바이트는 인덱스 62에서 + 및 인덱스 63에서 /를 생성합니다. base64url 결과를 표준으로 변환하는 것은 문자별 작업입니다. -를 스캔하고 +로 바꾸고, _를 스캔하고 /,로 바꾼 다음 평소대로 디코딩합니다.
인덱스가 동일했기 때문에 복구하는 바이트도 동일합니다. 기호만 다릅니다. base64url의 패딩은 표준에서 허용하더라도 관례에 따라 선택 사항입니다. JWT는 점으로 연결된 3개의 base64url 세그먼트로 구성됩니다. 각 세그먼트는 필요한 경우 패딩을 사용하지만 많은 구현에서는 이를 생략하고 소비 애플리케이션이 예상 바이트 길이를 알고 있다는 사실에 의존합니다.
작업 예: JWT 헤더 세그먼트를 표준 Base64로 변환 — 문자 교체, 패딩 추가, JSON로 디코딩
디코더는 문자열 길이를 4로 나누고 나머지를 계산하고 0, 1 또는 2 등호를 추가하여 누락된 패딩을 복원할 수 있습니다. 문자열 길이가 4의 배수가 아닌 경우 패딩이 누락된 것이 분명합니다. 길이가 4의 배수인 경우 문자열은 패딩된 다음 패딩이 제거되었거나 이미 4바이트의 배수를 입력했습니다(마지막 블록에서 3바이트로 끝나며 패딩이 필요하지 않음).
base64url 세그먼트를 연결하려면 패딩에 주의가 필요합니다. 세 개의 세그먼트가 각각 =로 끝나는 경우 연결하면 AAAA=BBBB=CCCC=와 같은 문자열이 직접 생성됩니다. 여기서 중간 패딩은 이제 종료 마커가 아닌 길 잃은 문자입니다. 이것이 JWT가 각 세그먼트의 패딩을 생략하는 이유입니다. 3세그먼트 구조는 명시적이므로 디코딩은 각 부분에서 독립적으로 진행되며 연결된 문자열 중간의 패딩은 불필요하며 구문 분석이 중단됩니다.
일반적인 실수 — 하나의 문자열에 알파벳을 혼합하거나 base64url을 사용하는 대신 표준 Base64를 퍼센트 인코딩합니다.
다중 세그먼트 페이로드를 구축하는 경우 시작 시 패딩 규칙을 결정합니다. 각 세그먼트에 포함하고 직접 연결하지 않거나 생략하고 디코딩할 때만 길이에서 복원합니다. RFC 4648 표준은 두 알파벳 모두에 대한 권위입니다. 4 섹션은 표준 Base64를 지정합니다. 5 섹션은 base64url을 지정합니다. 모든 규격 디코더는 어떤 알파벳을 허용하는지 명확하게 명시해야 합니다.
base64url을 허용하지만 표준 Base64는 허용하지 않는 코드(또는 그 반대)는 하위 집합만 구현하고 있습니다. base64url 알파벳은 URL 및 파일 이름 제약 조건과의 호환성을 위해 존재합니다. 이는 개선이나 교체가 아니며 특정 상황에 대한 변형일 뿐입니다. API 또는 토큰 형식을 작성할 때 하나의 알파벳과 문서를 선택하세요. 일반적인 실수는 base64url을 사용하는 대신 표준 Base64를 백분율로 인코딩하는 것입니다. 구현에서는 기사 경계도 설명합니다. 디코딩하기 전에 하이픈과 밑줄을 표준화하지만 토큰 서명을 확인하거나 주장을 해석하지는 않습니다. JWT 세그먼트를 바이트로 변환하면 JSON이 드러날 수 있습니다. JSON를 발행한 사람이 누구인지 또는 누군가가 이를 변경했는지 여부를 확인할 수 없습니다.
여기에 포함되지 않는 내용 — JWT 서명, base32 및 기타 RFC 4648 인코딩 확인
%2B는 +에 대한 백분율 코드입니다. %2F는 /.에 대한 백분율 코드입니다. 백분율 인코딩은 TWFu를 변경 없이 TWFu로 변환하지만(특수 문자 없음) TE9S+g==를 TE9S%2Bg%3D%3D(처리할 문자가 너무 많음)로 변환합니다. 올바른 해결책은 이미 URL 안전 출력을 생성하는 base64url을 사용하는 것입니다. 퍼센트 인코딩 Base64는 불필요하고 낭비입니다. 상황에 맞게 올바른 알파벳을 사용하세요. Base64 인코더 및 디코더는 두 알파벳을 자동으로 허용합니다.
-가 포함된 문자열을 붙여넣으면 base64url로 처리됩니다. +가 포함된 문자열을 붙여 넣으면 표준 Base64로 처리됩니다. 도구는 또한 URL을 허용하고 이를 URL 안전 입력으로 처리합니다. 따라서 실제 검사에는 두 가지 독립적인 결과가 있습니다. 즉, 바이트 왕복과 선택한 표현이 해당 채널에 적합합니다. 첫 번째를 통과하면 변환이 되돌릴 수 있음을 의미합니다. 두 번째를 전달하면 문장 부호와 패딩이 이를 전달하는 URL, 파일 이름, 쿠키 또는 프로토콜에 의해 다시 작성되지 않는다는 의미입니다.
요점: 알파벳 2개, 비트 레이아웃 1개 — Base64 인코더 및 디코더가 브라우저에서 표준 알파벳을 처리하는 방법과 해당 도구 페이지에서 허용되는 내용이 설명되는 위치
JWT 세그먼트 또는 URL 안전 토큰을 디코딩할 때 변환 없이 직접 붙여넣을 수 있으며 도구는 컨텍스트에서 알파벳을 식별합니다. 실패한 디코드 디버깅은 간단해집니다. 토큰을 붙여넣고 도구가 이를 허용하는지 확인하고, 그렇지 않은 경우 수동으로 문자를 바꾸고 다시 시도하세요.
대체 자체는 한 줄의 코드이지만 실패한 디코딩은 불가능한 길이, 잘못된 패딩, 손상 또는 Base64가 아닌 입력으로 인해 발생할 수도 있습니다. 이 도구는 두 알파벳을 자동으로 정규화하므로 수락하면 바이트를 복구할 수 있다는 것만 확인됩니다. 디코딩된 JWT 페이로드는 별도의 검증자가 서명과 예상 알고리즘을 확인할 때까지 여전히 서명되지 않은 클레임입니다.