개발자 도구 · JWT 디코더
base64 및 jq를 사용하여 직접 JWT 페이로드를 디코딩하는 방법
· 작동 방식
jwt 명령줄 개발자 워크플로
헤드리스 상자에서는 여전히 cut, tr, base64 및 jq를 사용하여 토큰을 읽을 수 있습니다. 이 게시물에서는 명령을 제공하고 각 명령이 수행하는 base64url 변환을 설명하며 함정을 나열합니다.
SSH를 통해 토큰 읽기 — 브라우저가 옵션이 아닌 경우
헤드리스 서버에서는 브라우저 UI 없이 토큰 모양의 문자열만 남길 수 있습니다. 필요한 검사 작업은 여전히 작습니다. 하나의 세그먼트를 분리하고, base64url 철자를 번역하고, 패딩을 복원하고, 바이트를 디코딩하고, JSON을 구문 분석합니다. 쉘 기록이 실시간 자격 증명을 보존할 수 있기 때문에 위험은 계산보다는 운영에 있습니다.
가능하면 만료된 토큰이나 합성 토큰을 사용하세요. 사고 대응에 실제 가치를 조사해야 하는 경우 조직의 자격 증명 처리 제어를 따르고 공유 기록이나 로그에 입력되는 것을 방지하고 노출 후 교체하십시오. 명령줄 디코딩은 검사 전용으로 유지됩니다. 확인 키나 신뢰 정책을 제공하지 않습니다.
점으로 분할 — 페이로드 세그먼트를 분리하려면 잘라내거나 awk
컴팩트 JWS 모양의 JWT에는 점으로 구분된 3개의 필드가 있습니다. 페이로드는 두 번째입니다. 쉘은 구분 기호 인식 도구를 사용하여 이를 분할할 수 있지만 쉘이 문자를 확장하거나 공백을 분할하지 않도록 변수를 인용합니다. 해당 접두사가 HTTP 구문에 속하므로 필드를 선택하기 전에 선행 `Bearer ` 레이블을 제거하십시오.
필드 2를 맹목적으로 취하지 말고 필드 수를 세십시오. ToolAcre는 세 부분 이외의 모든 부분을 거부하고 다섯 부분으로 구성된 암호화된 입력을 별도로 식별합니다. 셸 파이프라인은 동일한 구조적 주의를 적용해야 합니다. 잘못된 입력에서 세그먼트를 수신하면 원래 토큰이 잘린 것을 숨기면서 그럴듯한 JSON을 생성할 수 있습니다.
알파벳 변환 — 하이픈과 밑줄을 다시 더하기와 슬래시로 바꾸는 tr
표준 명령줄 Base64 구현에서는 일반적으로 JWT 세그먼트에 하이픈과 밑줄이 포함될 수 있는 플러스와 슬래시가 필요합니다. `-`을 `+`로, `_`을 `/`로 변환하면 표시된 6비트 값을 변경하지 않고 URL 안전 기호가 표준 위치로 다시 매핑됩니다.
옵션 구문 분석에서 선행 하이픈을 플래그로 착각할 수 없는 변환 명령을 사용하고 데이터를 인용된 변수 또는 표준 입력에 유지하십시오. 알파벳 변환은 가역적 인코딩 작업입니다. 클레임의 암호를 해독하지 않으며 성공하더라도 해당 토큰이 명명된 발급자로부터 왔다는 사실이 입증되지 않습니다.
패딩 복원 — 올바른 수의 등호를 추가하는 산술
변환 후 모듈로 4의 길이를 계산합니다. 나머지 0에는 등호가 필요하지 않고 나머지 2에는 2가 필요하며 나머지 3에는 1이 필요합니다. 나머지 1은 잘림을 나타내며 파이프라인을 중지해야 합니다. 유틸리티가 불평을 멈출 때까지 임의의 패딩을 추가하면 손상을 진단하기보다는 숨길 수 있습니다.
ToolAcre는 `base64ToBytes`에서 정확히 이 길이 규칙을 사용하고 불가능한 나머지를 거부합니다. 셸 유틸리티는 생략된 패딩을 허용하는지 여부에 따라 다르므로 먼저 입력을 정규화하면 개념상 파이프라인이 명시적이고 이식 가능해집니다. 단, 명령 플래그는 여전히 운영 체제마다 다를 수 있습니다.
디코딩 및 예쁜 인쇄 — jq에 파이프된 base64 -d
패딩된 값을 플랫폼의 Base64 디코더에 파이프한 다음 `jq`에 파이프합니다. 첫 번째 명령은 바이트를 복구합니다. 두 번째는 JSON을 형성하기 위해 해당 바이트가 필요합니다. 성공적인 Base64 명령 뒤에 jq 구문 분석 오류가 발생하면 인코딩은 구조적으로 디코딩 가능하지만 해당 콘텐츠는 JSON 페이로드가 아님을 의미합니다.
이러한 구별은 ToolAcre의 오류 경로를 반영합니다. 먼저 잘못된 base64url 또는 UTF-8을 보고한 다음 잘못된 JSON을 별도로 보고한 다음 JWT 헤더 또는 페이로드가 이 도구의 개체여야 하므로 null, 배열 및 프리미티브를 거부합니다. 단계를 분리하여 유지하면 실패에 대한 조치가 가능해집니다.
작업된 예 — 각 단계의 출력이 포함된 샘플 토큰의 전체 파이프라인
종합적인 예의 경우 페이로드 세그먼트 `eyJzdWIiOiJkZW1vIiwicm9sZSI6InJlYWRlciJ9`에는 알파벳 번역이나 패딩이 필요하지 않습니다. 디코딩하면 `{"sub":"demo","role":"reader"}`이 생성되고 jq는 여러 줄에 걸쳐 개체를 포맷합니다. 표시되는 역할은 토큰에서 제공하는 문자열일 뿐입니다.
이제 JSON을 변경하고 다시 인코딩한 후 세 번째 세그먼트를 연결합니다. 파이프라인은 여전히 변경된 개체를 인쇄합니다. 이는 디코드 명령이 유효성 검사 역할을 할 수 없는 이유를 입증합니다. 별도의 검증자가 서명을 확인하지 않는 한 합법적인 주장과 조작된 주장 모두 동일한 공개 변환을 통과합니다.
함정 — 토큰을 캡처하는 쉘 기록, 누락된 패딩을 거부하는 base64 구현 및 앞에 'Bearer'가 있는 토큰
일반적인 실패에는 HTTP 접두사 유지, 잘못된 점으로 구분된 필드 선택, 복사 중 후행 문자 손실, 패딩이 필요한 Base64 구현 사용 등이 포함됩니다. 또 다른 함정은 프로세스 목록이나 기록에 토큰이 보관될 수 있는 명령줄에 전체 토큰을 직접 배치하는 것입니다.
적절한 제어 하에 있는 표준 입력 및 임시 변수를 선호하고, 편의를 위해 생산 토큰을 채팅, 티켓 또는 공유 터미널에 붙여넣지 마십시오. 또한 세 번째 세그먼트는 JSON이 아닌 바이너리 서명 자료이므로 jq를 통해 전송하면 실패하고 서명 유효성에 대해 아무 것도 알려주지 않습니다.
요점: 모든 환경에서 동일한 디코딩 — 브라우저가 있는 경우 ToolAcre JWT 디코더는 아무것도 업로드하지 않고 로컬에서 이 작업을 수행합니다.
셸 파이프라인과 ToolAcre는 서로 다른 환경에서 동일한 디코드 전용 시퀀스(분할, 정규화, 패드, UTF-8 디코딩 및 JSON 구문 분석)를 수행합니다. 민감하지 않은 데이터를 기본값으로 검사하고 제어할 수 있는 환경을 사용하세요.
두 경로 모두 진위 여부를 확인하거나 호출자에게 권한을 부여하지 않습니다. 페이로드 형태를 읽은 후 서비스의 신뢰할 수 있는 검증자로 이동하고 암호화 및 정책 결정에 대한 로그를 기록합니다. 꽤 JSON을 생성하는 명령은 보안 판단이 아닌 포맷 작업을 완료했습니다.