서명하는 쪽과 검증하는 쪽을 분리해, 검증 권한만 신뢰 경계 밖으로 내보냅니다.
HMAC은 서명과 검증에 같은 비밀을 쓰므로, 검증할 수 있는 쪽은 위조도 할 수 있습니다. 비대칭 서명은 개인키로 서명하고 공개키로 검증해 이 둘을 나눕니다. 공개키는 공개해도 되니 검증자를 여럿 두어도 발급 권한은 퍼지지 않습니다. 키 식별자를 공개키에서 계산하면 배포 중에 키가 뒤바뀐 것도 잡아낼 수 있습니다.
개인키는 발급자만, 공개키는 검증자가 갖게 해 검증 권한과 발급 권한을 나눕니다.
토큰이 스스로 밝힌 alg를 믿지 않고 검증자가 알고리즘을 정해 두어 혼동 공격을 막습니다.
키 식별자를 공개키에서 계산하므로, 이름 붙이는 규칙이 아니라 값 자체로 키와 식별자가 묶입니다.
아래 증명은 글로 된 설명이 아닙니다. 버튼을 누르면 이 서버가 지금 직접 계산합니다.
검증자에게는 공개키만 있으면 됩니다. 개인키 없이 서명을 확인할 수 있으므로, 검증하는 쪽도 서명을 위조하지는 못합니다. HMAC과 갈리는 지점이 바로 여기입니다. kid는 임의로 붙인 이름이 아니라 공개키에서 유도한 지문입니다.
표준 문서에 실린 테스트 벡터를 그대로 넣어 같은 값이 나오는지 확인합니다.
공개키는 누구나 볼 수 있습니다. 검증자가 토큰의 alg 헤더를 믿고 검증 방식을 고르면, 공격자는 alg를 HS256으로 바꾸고 그 공개키를 HMAC 키로 삼아 토큰을 만들어 냅니다. 검증자가 알고리즘을 고정해야만 막을 수 있습니다.
막아야 할 입력을 실제로 넣고 거부되는지 확인합니다.
규격 원문을 먼저 실었습니다. 사례는 이 분야에서 실제로 보안이 뚫린 일을 다룬 자료입니다.
서명 구조와 검증 절차를 정의합니다. 부록 A.3이 ES256 예시입니다.
kid를 공개키에서 유도하는 계산 방법입니다.
공개키를 HMAC 키로 쓰게 만드는 혼동 공격과 그 대응을 다룹니다.
다음 단계
소비 시스템의 KMS에 개인키를 두고 자기 도메인에 JWKS를 게시한 뒤, 여러 키가 함께 쓰이는 rollover 기간에 검증이 어떻게 동작하는지 확인합니다.