개발자 도구 · JWT 디코더
RFC 7519 및 JOSE 제품군: JWT, JWS, JWE, JWK 및 JWA 설명
· 배경
jwt 암호화 표준
JWT은 IETF JOSE 작업 그룹의 사양 제품군 중 하나입니다. 이 게시물에서는 각 RFC가 정의하는 내용, 서로 어떻게 결합되는지, JWT이 일반적으로 JWS인 이유를 설명합니다.
5개의 약어, 1개의 토큰 — JWT에 대해서만 질문했는데 문서에서 JWS 및 JWE를 언급하는 이유는 무엇입니까?
토큰 문서는 동일한 생태계의 다양한 계층을 설명하기 때문에 JWT, JWS, JWE, JWK 및 JWA 간에 이동됩니다. "JWT"이 세 부분으로 구성된 모든 소형 서명 토큰에 대한 약칭으로 사용될 때 혼란이 시작됩니다. 봉투 및 키 표현에서 클레임을 분리하면 구현을 더 쉽게 추론할 수 있습니다.
ToolAcre의 디코더는 의도적으로 제품군보다 좁습니다. 처음 두 개의 디코딩된 세그먼트가 JSON 개체인 세 부분으로 구성된 JWS 모양의 입력을 처리합니다. 수신자 키 없이 암호문을 읽는 것은 동일한 내용을 디코딩하지 않기 때문에 다섯 부분으로 구성된 암호화된 압축 입력을 감지하고 중지합니다.
JOSE 문서는 관련 형식을 정의합니다. 이 저장소는 작업 그룹 타임라인을 설정하지 않습니다.
관련 사양은 IETF JOSE 작업에서 나왔지만 저장소 소스는 개요에서 요청한 자세한 조직 일정을 설정하지 않습니다. 따라서 이 기사에서는 날짜나 프로세스 기록을 만들어내는 것을 피하고 도구와 계획에서 관찰할 수 있는 형식 관계에 중점을 둡니다.
실질적인 질문은 어느 계층이 각 결정을 소유하는지입니다. 클레임 이름은 애플리케이션 문을 설명하고, 서명은 인코딩된 자료를 보호하고, 암호화는 콘텐츠를 보호하고, JSON 키 개체는 키 정보를 나타내고, 알고리즘 식별자 이름 작업을 나타냅니다. 어떤 약어도 다른 약어를 대체하지 않습니다.
JWS (RFC 7515) — 임의 콘텐츠 서명 및 압축 직렬화 JWT 사용
JWS는 서명된 콘텐츠 또는 MAC으로 보호되는 콘텐츠를 설명합니다. 컴팩트 형식에는 보호된 헤더, 페이로드 및 서명의 세 부분이 있습니다. 서명 입력은 점으로 연결된 처음 두 개의 인코딩된 세그먼트를 사용합니다. JWT는 일반적으로 ToolAcre가 분할하고 검사하는 형식인 이 봉투에서 이동합니다.
헤더와 페이로드는 JSON로 디코딩될 수 있지만 서명은 세 번째 객체가 아닌 바이트입니다. ToolAcre는 서명 존재 및 크기를 보고하지만 항상 확인되지 않은 것으로 표시합니다. 따라서 암호화 결과를 요구하지 않고 JWS 구조를 설명할 수 있습니다.
JWE (RFC 7516) — 5부분으로 구성된 직렬화를 사용하여 콘텐츠 암호화
JWE는 암호화된 콘텐츠를 설명합니다. 컴팩트한 형태에는 보호된 헤더, 암호화된 키 자료, 초기화 값, 암호문 및 인증 태그를 나타내는 5개의 세그먼트가 있습니다. 따라서 네 개의 점은 세 부분으로 구성된 JWT 디코더가 다른 엔벨로프를 수신했다는 강력한 구조적 단서입니다.
ToolAcre는 특정 JWE 오류를 내보내고 암호 해독 키 없이는 내용을 읽을 수 없다고 설명합니다. 암호문을 잘못된 형식의 JSON로 처리하거나 임의 바이트를 표시하려고 시도하지 않습니다. 암호화 및 서명도 구성할 수 있지만 중첩된 처리는 이 경로 외부에 있습니다.
JWK 및 JWA(RFC 7517 및 7518) — 키를 JSON로 나타내고 알고리즘 이름 지정
JWK는 암호화 키 정보에 대한 JSON 표현을 제공하는 반면 JWA는 JOSE 전체에서 사용되는 알고리즘 식별자 및 관련 매개변수의 이름을 지정합니다. 토큰이 존재한다고 해서 토큰이 자체적으로 신뢰할 수 있는 키나 알고리즘을 선택할 수 있다는 의미는 아닙니다. 검증자는 발급자와 애플리케이션 정책 모두를 제한해야 합니다.
ToolAcre 알고리즘 노트는 소스에 있는 유한한 레이블 세트만 설명하고 인식되지 않는 다른 항목을 호출합니다. 이는 구현이 아니라 설명입니다. 디코더는 JWK를 가져오지도 않고 검사 경계를 명시적으로 유지하는 JWA의 알고리즘을 수행하지도 않습니다.
JWT (RFC 7519) — JWS 또는 JWE를 기반으로 하는 청구 형식
JWT는 클레임 개체와 발급자, 주체, 대상 및 NumericDates와 같은 등록된 이름을 정의합니다. 이러한 클레임은 서명되거나 암호화된 JOSE 구조로 전달될 수 있습니다. 따라서 페이로드 계층은 "어떤 문이 표시되는지"에 답하고, 봉투는 해당 바이트가 어떻게 보호되거나 숨겨지는지 답합니다.
ToolAcre는 디코딩된 페이로드가 JSON 개체일 것으로 예상하고 해당 클레임을 나열합니다. 이 도구에서는 배열, 숫자 또는 null이 거부됩니다. 구성된 검증자 또는 수신자가 관련 봉투를 처리할 때까지는 모양이 좋은 객체라도 신뢰할 수 없는 상태로 유지됩니다.
여기서 다루지 않는 내용 — 자체 게시물이 있는 RFC 8725 모범 사례 및 RFC 9068 액세스 토큰과 같은 최신 프로필
이후의 모범 사례 및 프로필 문서에서는 이러한 일반 메커니즘을 사용해야 하는 방법을 좁힐 수 있습니다. 기본 형식은 애플리케이션별 발급자, 대상자 또는 토큰 유형 정책을 제공하지 않으므로 별도로 처리할 가치가 있습니다. 이 문서에서는 디코더가 그러한 프로필을 구현한다고 주장하지 않습니다.
시스템을 검토할 때 정확한 프로필, 예상 범위, 허용되는 알고리즘, 키 소스 및 클레임 규칙을 기록합니다. 이 목록은 두문자어 친숙함이 호환성이나 보안에 대한 가정으로 바뀌는 것을 방지합니다.
요점: JWT은 클레임이고 JWS는 봉투입니다. ToolAcre JWT 디코더는 JWS 압축 형식을 읽고 내부의 JWT 헤더와 클레임을 표시합니다.
JWT는 클레임 레이어의 이름을 지정합니다. JWS와 JWE는 보호 봉투를 제공합니다. JWK는 핵심 데이터를 나타냅니다. JWA는 알고리즘 선택을 명명합니다. ToolAcre는 일반적인 세 부분으로 구성된 서명된 모양을 읽고 확인 또는 암호 해독을 거부하면서 헤더와 클레임을 표시합니다.
해당 지도를 사용하여 올바른 다음 질문을 하세요. 읽기 가능한 JSON은 클레임 레이어를 식별합니다. 3개 또는 5개의 세그먼트가 가능성 있는 봉투 계열을 식별합니다. 신뢰는 여전히 약어를 인식하는 디코더가 아니라 독립적으로 구성된 암호화 및 정책에 달려 있습니다.