개발자 도구 · JWT 디코더
ID 토큰과 액세스 토큰: OpenID Connect JWT이 API 키가 아닌 이유
· 배경
jwt 인증 인증
둘 다 동일한 공급자의 JWT일 수 있지만 서로 다른 질문에 대답합니다. 이 게시물에서는 ID 토큰과 액세스 토큰에 각각 무엇이 포함되어 있는지, 누가 소비해야 하는지, 디코딩을 통해 구분하는 방법을 설명합니다.
API는 완벽하게 유효해 보이는 토큰을 거부합니다. 이는 API용으로 만들어진 것이 아니기 때문입니다.
자격 증명이 다른 소비자 및 목적을 위해 발급되었기 때문에 API는 올바른 형식의 올바르게 서명된 토큰을 거부할 수 있습니다. “JWT입니다”는 가능한 형식을 설명하는 것이지 어디든 보낼 수 있는 권한이 아닙니다. ID 토큰과 액세스 토큰은 ID 흐름의 다양한 질문에 답합니다.
ToolAcre는 디버깅을 지원하는 헤더 및 페이로드 패턴을 노출할 수 있지만 토큰을 인증하거나 OpenID Connect 프로필의 유효성을 검사할 수는 없습니다. 최종 분류는 육안 검사가 아닌 공급자 계약, 발급 흐름 및 신뢰할 수 있는 검증 결과에 따라 이루어져야 합니다.
ID 토큰 클레임은 ID 사용을 제안할 수 있습니다. 이 일반 디코더는 OpenID Connect 프로필의 유효성을 검사하지 않습니다.
ID 토큰은 로그인을 요청한 클라이언트에 인증 정보를 전달합니다. 프로필에 따라 표시되는 클레임에는 nonce, 인증 시간, 인증 방법 또는 다른 토큰과 관련된 해시가 포함될 수 있습니다. 해당 필드는 일반 API 승인 부여가 아닙니다.
디코더는 `auth_time`을 시간 모양 필드로 처리하고 핵심 7개에 속하지 않는 한 다른 이름을 애플리케이션별 이름으로 표시합니다. nonce, `at_hash`, `amr` 또는 클라이언트 대상 의미 체계를 검증하지 않습니다. 읽을 수 있는 ID 페이로드는 클라이언트가 이를 올바르게 검증할 때까지 신뢰할 수 없는 상태로 유지됩니다.
액세스 토큰은 JWT이거나 불투명할 수 있습니다. 세 부분으로 구성된 JWT만 이 디코더에 적합합니다.
액세스 토큰은 인증 시스템에 따라 리소스 서버에 대한 호출을 인증합니다. JWT 또는 불투명 문자열일 수 있습니다. 세 부분으로 구성된 서명된 모양만이 ToolAcre의 경로에 맞습니다. 불투명 토큰에는 디코딩할 일반적인 클라이언트측 구조가 없으므로 이 도구를 통해 강제로 적용해서는 안 됩니다.
JWT 액세스 토큰은 대상 및 범위 정보를 전달할 수 있지만 해당 값에는 인증된 확인 및 리소스 정책이 필요합니다. 브라우저 패널은 리소스 서버를 구현하지 않으며 범위가 특정 작업을 허용하는지 여부를 알 수 없습니다.
새로 고침 토큰 — 일반적으로 불투명하며 디코딩할 의도가 없으며 API로 전송되지 않습니다.
새로 고침 토큰은 공급자 규칙에 따라 대체 액세스 자격 증명을 얻는 것을 지원합니다. 일반적으로 불투명하며 리소스 API용으로 사용되지 않습니다. 이는 또한 가치가 높은 자격 증명이므로 디코더에 붙여넣으면 신뢰할 수 있는 진단 이점 없이 위험을 초래할 수 있습니다.
모든 토큰 형태의 값을 디코딩해야 한다고 추론하지 마세요. 새로 고침 실패에 대해 공급자 도구 및 제어 로그를 사용합니다. 생산 토큰에 대한 ToolAcre의 명시적인 경고는 여기서 특히 강력하게 적용되며 3세그먼트 파서는 새로 고침 작업을 제공하지 않습니다.
대상이 다릅니다. ID 토큰의 클라이언트 ID와 액세스 토큰의 리소스
잠재고객은 의도한 소비자가 다르기 때문에 강력한 단서입니다. ID 토큰은 클라이언트를 대상으로 하는 경우가 많지만 액세스 토큰은 리소스를 대상으로 하는 경우가 많습니다. 정확한 식별자와 표현은 공급자와 프로필에 따라 다르므로 이 문서에서는 범용 문자열 패턴을 고안하지 않습니다.
헤더 `typ`도 명시적인 레이블을 제공할 수 있지만 확인될 때까지 토큰 제어 데이터로 유지됩니다. ToolAcre는 `typ` 문자열이 `JWT`과 다른 경우에만 경고합니다. 모든 프로필 레이블을 인식하거나 이를 승인 결정으로 바꾸지는 않습니다.
실제 예: 표시되는 필드를 토큰 유형의 증거로 처리하지 않고 비교
두 개의 합성 예제를 디코딩합니다. 하나는 클라이언트 지향 인증 클레임을 전달하고 다른 하나는 리소스 대상 및 범위를 전달합니다. `aud`, `typ` 및 페이로드 이름의 차이점을 기록합니다. 이 연습에서는 두 예시의 신원을 증명하는 방법이 아니라 발급자에게 무엇을 물어봐야 하는지 가르쳐줍니다.
조작된 토큰은 동일한 레이블을 복사할 수 있으며 실제 토큰은 공급자별 규칙을 사용할 수 있습니다. 발급 응답 및 문서에서 유형을 확인한 다음 대상 소비자에게 유효성을 검사합니다. 디코더의 출력은 결정 권한이 아니라 증거를 뒷받침합니다.
여기서 다루지 않는 내용 — 별도의 주제인 이러한 토큰을 발행하는 OAuth 흐름
이 비교에서는 인증 코드, 장치 또는 토큰을 발행하는 기타 흐름을 설명하지 않습니다. 또한 공급자별 유효성 검사 단계, 불투명한 액세스 토큰 검사 또는 새로 고침 회전을 다루지 않습니다. 해당 주제는 선택한 생태계 및 배포에 따라 다릅니다.
즉각적인 디버깅 질문을 좁게 유지하세요. 클라이언트가 받은 자격 증명은 무엇인지, 의도한 소비자는 누구인지, 이를 검증하는 신뢰할 수 있는 구성 요소는 무엇입니까? 이 세 가지 질문에 대답하면 일반 JWT 형태가 프로토콜 역할을 지우는 것을 방지할 수 있습니다.
요점: 보내기 전에 aud 및 typ를 살펴보십시오. ToolAcre JWT 디코더를 사용하면 보유하고 있는 토큰 종류를 확인할 수 있습니다.
토큰을 보내기 전에 대상과 유형을 살펴보세요. 단, 확인이 성공할 때까지 어느 필드도 신뢰하지 마십시오. ID 토큰은 클라이언트 유효성 검사 경계에 속합니다. 액세스 토큰은 리소스 서버에 속합니다. 새로 고침 토큰은 API가 아닌 공급자의 새로 고침 프로세스에 속합니다.
ToolAcre는 안전한 세 부분으로 구성된 예제를 읽는 데 도움을 주며 이를 분류하거나 검증한다고 주장하지 않습니다. 이를 사용하여 발생할 수 있는 실수를 발견한 다음 문서화된 흐름과 독립적으로 구성된 검증자가 자격 증명의 실제 목적을 확립하도록 하십시오.