JWT 서명 검증 도구 (RS256/ES256, 공개키 검증)

RS256 또는 ES256으로 서명된 JWT(JSON Web Token)를 SPKI 형식의 공개키(PEM)를 사용해 브라우저에서 바로 검증할 수 있는 개발자용 도구입니다. 헤더·페이로드 디코딩 결과와 만료 여부도 함께 확인할 수 있습니다. 입력한 내용은 서버로 전송되지 않고 브라우저 내에서만 처리됩니다.

지원하는 서명 알고리즘 목록

알고리즘 키 종류 해시 함수 설명
RS256 RSA (RSASSA-PKCS1-v1_5) SHA-256 RSA 공개키 암호 방식을 사용한 서명. Google·Auth0·Okta 등 주요 OAuth 2.0/OpenID Connect 제공자가 ID 토큰에 사용하는 기본 알고리즘입니다.
ES256 ECDSA (P-256 타원곡선) SHA-256 RSA보다 짧은 키 길이와 서명 크기로 동등한 안전성을 확보할 수 있는 타원곡선 암호 서명 방식으로, 모바일 앱과 IoT 기기 등에서 채택이 늘고 있습니다.

  • 입력하는 공개키는 PEM 형식(SPKI, "-----BEGIN PUBLIC KEY-----"로 시작)이어야 합니다. 개인키 파일이나 인증서(.crt)를 그대로 붙여넣으면 검증되지 않습니다.
  • JWT 헤더의 alg 필드 값(RS256 또는 ES256)에 따라 내부적으로 사용하는 검증 알고리즘이 자동으로 전환되므로 수동 선택은 필요하지 않습니다.
  • 서명 검증과 동시에 페이로드의 exp 클레임도 확인해 만료 시 경고를 표시합니다. 서명이 올바르더라도 만료된 토큰은 원래 거부해야 합니다.
  • 이 도구는 RS256·ES256만 지원합니다. HS256 같은 공유키 방식의 JWT를 확인하려면 자매 도구인 JWT 인코더에서 동일한 비밀키로 다시 서명해 결과를 비교하는 방법이 있습니다.
  • 검증에 사용하는 공개키는 비밀 정보가 아니므로, ID 공급자의 공개 엔드포인트(JWKS 등)에서 얻은 값을 그대로 붙여넣어도 문제없습니다.

자주 묻는 질문

RS256과 ES256만 검증할 수 있습니다. HS256·HS384·HS512는 비밀키를 공유하는 공유키 방식이므로 공개키만 입력하는 이 도구의 구조로는 검증할 수 없습니다. HS256 서명을 확인하려면 자매 도구인 JWT 인코더에서 동일한 비밀키로 다시 서명해 생성 결과가 일치하는지 비교하는 방법이 있습니다.

Google·Auth0·Okta 같은 ID 공급자는 JWKS(JSON Web Key Set)라는 공개 엔드포인트를 통해 공개키를 배포합니다. JWKS 형식의 JSON을 PEM 형식으로 변환하는 도구를 사용하거나, 연동하려는 서비스의 문서에 기재된 공개키를 그대로 사용하세요.

주요 원인은 ①입력한 공개키가 해당 JWT를 발급한 개인키와 짝이 아니거나, ②JWT의 헤더·페이로드·서명 중 일부가 전송 중 변조·손상되었거나, ③복사 과정에서 문자가 누락된 경우입니다. JWT 문자열과 공개키 모두 발급처에서 다시 정확히 복사해 보세요.

현재는 RS256·ES256만 지원합니다. RS384/RS512·ES384/ES512처럼 더 긴 해시 함수를 사용하는 변형은 향후 지원 검토 대상입니다.

네, 서명의 정당성과 exp 만료 여부는 각각 독립적으로 판정되어 함께 표시됩니다. 서명이 올바르더라도 만료된 토큰은 실제 시스템에서는 보통 거부해야 하므로, 화면에 표시되는 유효기간 경고도 반드시 확인하세요.
ツールくん

여담 ― HMAC와 공개키 서명, 무엇이 다를까

JWT 서명 방식은 크게 공유키 방식(HMAC, HS256 등)과 공개키 방식(RSA/ECDSA, RS256·ES256 등)으로 나뉜다. 공유키 방식은 서명하는 쪽과 검증하는 쪽이 동일한 비밀 문자열을 공유해야 하는 반면, 공개키 방식에서는 서명하는 쪽만 개인키를 가지고 있으면 되며 검증하는 쪽은 누구나 얻을 수 있는 공개키만으로 검증할 수 있다. 이 차이는 API 설계에서 역할 분담에 직결된다. 자매 도구인 JWT 인코더(HS256)는 "발급자와 검증자가 같은 서버 안에서 끝나는" 용도에 적합하고, 이 도구가 다루는 RS256·ES256은 "발급자와 검증자가 서로 다른 조직·다른 서버인" 용도에 적합하다고 바꿔 말할 수 있다.

실제로 Google의 OAuth 2.0, OpenID Connect, Auth0, Okta 같은 주요 ID 공급자가 발급하는 ID 토큰은 거의 예외 없이 RS256으로 서명된다(ES256을 대안으로 선택할 수 있는 경우도 많다). 이는 ID 공급자 쪽만 개인키로 서명하고, 무수히 많은 클라이언트 애플리케이션(검증하는 쪽)은 공개키만으로 검증할 수 있게 하기 위해서다. 모든 클라이언트에 비밀키를 배포할 필요가 없으므로 키 유출 위험을 서명자 쪽 한 곳으로 한정할 수 있다.

RS256과 ES256은 둘 다 SHA-256으로 해시를 계산한다는 점은 같지만 암호 방식 자체가 다르다. RS256은 RSA 암호(일반적으로 2048비트 이상의 키 길이)를 사용하므로 서명 크기가 커지기 쉽지만, 구현이 성숙하고 지원 라이브러리가 많다는 강점이 있다. ES256은 타원곡선 암호(P-256)를 사용해 RSA보다 훨씬 짧은 키·서명 크기로 동등한 안전성을 확보할 수 있어, 모바일 환경이나 페이로드 크기를 줄이고 싶은 API에서 채택이 늘고 있다.

→ 모든 여담 보기