개발자 도구 · JWT 디코더
대상 및 발급자 확인: JWT이 다른 곳에서 재생되는 것을 중지
· 그것이 중요한 이유
jwt 인증 보안
한 서비스에 대해 발행된 토큰은 동일한 발행자를 공유하는 다른 서비스에 제공될 수 있습니다. 이 게시물에서는 aud 및 iss 검사가 이를 중지하는 방법과 토큰에서 두 클레임을 읽는 방법을 설명합니다.
서비스 B는 서비스 A용 토큰을 허용합니다. 즉, 유효한 서명이 방지되지 않는 서비스 간 재생입니다.
서명은 다른 서비스에 발급된 토큰에 유효할 수 있습니다. 여러 API가 동일한 ID 플랫폼을 신뢰하지만 수신자 컨텍스트를 무시하는 경우 서비스 A용 자격 증명이 서비스 B에서 재생될 수 있습니다. 암호화 무결성만으로는 누가 이를 사용해야 하는지 대답할 수 없습니다.
ToolAcre는 `iss` 및 `aud`을 공개하여 개발자가 명백한 불일치를 발견할 수 있습니다. 이러한 문자열은 서명이 성공할 때까지 확인되지 않은 상태로 유지되며 브라우저 도구는 해당 확인을 수행하지 않습니다. 실제 리소스 서버는 발급자 관계와 대상 사용자를 모두 적용해야 합니다.
iss — 서비스가 신뢰하는 발급자에 토큰을 바인딩하고 키 바인딩 없이는 문자열 일치가 충분하지 않은 이유
`iss`은 페이로드가 토큰을 발행했다고 주장하는 엔터티를 식별합니다. 검증자는 자체 구성에 따라 정확한 예상 발급자가 필요하며 해당 ID를 올바른 키 검색 관계에 바인딩해야 합니다. 암호화 바인딩 없이 텍스트를 비교하면 공격자가 예상되는 문자열을 복사할 여지가 남습니다.
디코더는 `iss`을 "토큰을 만든 사람"으로 설명하지만 이는 붙여넣은 값에 대한 결과가 아니라 등록된 의미입니다. 읽을 수 있는 발급자 텍스트는 구성 디버깅에 유용한 증거입니다. 임의의 키 소스를 선택하거나 자신을 인증할 수 없습니다.
aud — 의도된 수신자를 명명하는 문자열 또는 배열과 검증자가 그 안에서 자신을 찾아야 하는 규칙
`aud`는 의도된 수신자의 이름을 지정하며 하나의 문자열 또는 모음으로 나타날 수 있습니다. 리소스 서버의 정책은 프로필에서 요구하는 정확한 비교 규칙을 사용하여 인증된 값에서 자신을 찾아야 합니다. 단지 다른 친숙한 서비스가 나열되어 있다는 이유만으로 토큰을 허용해서는 안 됩니다.
ToolAcre는 클레임 테이블에 배열을 JSON 텍스트로 전달하여 검사를 위해 눈에 보이는 구조를 유지합니다. 현재 API의 식별자를 모르며 일치 여부를 결정할 수 없습니다. 이러한 고의적인 부재로 인해 일반 디코더가 소유하지 않은 인증 컨텍스트를 만들어내는 것이 방지됩니다.
azp 및 범위 — 토큰을 사용할 수 있는 사람과 대상을 구체화하는 OpenID Connect 및 OAuth 클레임
`azp` 및 `scope`은 승인된 당사자에 대한 컨텍스트를 추가하고 이를 정의하는 프로필에 요청된 권한을 추가할 수 있습니다. 이는 대상자, 발급자 또는 서명 확인을 대체하지 않습니다. 범위 이름은 리소스 서버가 인증된 값을 자체 정책에 매핑할 때까지 권한 부여가 아니라 어설션입니다.
현재 디코더는 등록 설명 테이블이 7개의 핵심 이름을 다루기 때문에 이를 애플리케이션별 클레임으로 처리합니다. 해당 값을 표시하지만 OpenID Connect 또는 OAuth 의미 체계를 제공하지 않습니다. 결정에 사용하기 전에 해당 프로필 및 제공업체 계약을 참조하세요.
혼란스러운 대리인 패턴 — 청중을 확인하지 않을 때 합법적인 토큰이 어떻게 공격이 되는지
혼란스러운 대리인이 의도하지 않은 상황에서 합법적인 권한을 사용합니다. 잘못된 서비스에서 수락한 토큰은 아무도 서명을 위조하지 않은 경우에도 정확히 해당 패턴을 트리거할 수 있습니다. 청중은 인증된 청구가 적용될 수 있는 제한을 확인하고, 발급자는 서비스가 고려하는 주장의 제한을 확인합니다.
이것이 일반적인 "서명 유효" 플래그가 여전히 불충분한 이유입니다. 승인은 수신자와 작업에 따라 다릅니다. ToolAcre는 확인 결과를 보고하지 않고 소비 서비스가 암호화와 상황별 정책을 결합하도록 함으로써 이러한 모호성을 완전히 방지합니다.
실제 예 — ToolAcre JWT 디코더의 두 토큰에서 iss 및 aud를 읽고 어떤 서비스가 각각을 수락해야 하는지 결정
디코딩된 페이로드가 `aud`에서만 다른 두 개의 무해한 토큰을 만듭니다. 하나는 `service-a`, 다른 하나는 `service-b`입니다. 둘 다 동일한 발행자를 주장합니다. ToolAcre는 차이를 눈에 띄게 만듭니다. 서비스 A 검증자는 이 디스플레이에서만 수락해서는 안 되며 인증된 서비스 B 대상을 거부해야 합니다.
그런 다음 두 개의 발급자 문자열을 사용하여 연습을 반대로 수행합니다. 해당 발급자가 신뢰할 수 있는 키를 사용하여 확인하지 않는 한 예상되는 텍스트만으로는 충분하지 않습니다. 이러한 예는 검사와 승인을 분리하고 올바른 주장을 조작된 토큰에 복사해도 신뢰할 수 있는 정책이 변경되지 않는 이유를 보여줍니다.
여기서 다루지 않는 것 — 디코더가 절대 수행하지 않는 서명 확인; aud 및 iss는 서명이 유지된 후에만 문제를 확인합니다.
대상자 및 발급자 확인은 암호화 검증을 통해 보호된 바이트가 신뢰할 수 있는 키 자료와 일치함을 확인한 후에만 중요합니다. ToolAcre는 해당 확인을 수행하지 않습니다. 해당 출력에서는 클레임이 그대로 유지되었거나 알려진 발급자가 이를 작성했다는 사실을 확인할 수 없습니다.
또한 메타데이터를 가져오거나 키를 선택하거나 구성된 수신자를 비교하지 않습니다. 백엔드 테스트와 로그를 사용하여 잘못된 발급자와 잘못된 대상에 대한 거부를 증명하세요. 디코더의 시각적 일치는 디버깅 단서일 뿐, 충분한 인증 증거는 아닙니다.
요약: 서명한 사람뿐만 아니라 누구를 위한 것인지 확인하세요. ToolAcre JWT 디코더는 비교해야 할 감사 및 iss 주장을 보여줍니다.
서명한 이름뿐만 아니라 토큰이 누구를 위한 것인지 확인하세요. 강력한 흐름은 독립적으로 신뢰할 수 있는 발급자 관계에서 보호된 바이트를 인증한 다음 허용 가능한 대상이 필요하고 서비스별 권한 부여 규칙을 적용합니다.
ToolAcre를 사용하여 안전한 테스트 값을 읽고 다음 서버 측 검사를 공식화합니다. 신뢰할 수 없는 헤더 또는 클레임 데이터에서 확인 키를 선택하지 말고 표시된 `iss`, `aud`, `azp` 또는 `scope`을 완전히 신뢰할 수 있는 흐름 없이 승인으로 전환하지 마세요.