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

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

마지막 업데이트: 2026-09-20

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

알고리즘	키 종류	해시 함수	설명
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 기기 등에서 채택이 늘고 있습니다.

공개 키로 JWT 서명을 검증하기

이 도구는 RS256이나 ES256으로 서명된 JWT를 SPKI 형식의 PEM 공개 키로 검증하며, 디코딩한 헤더와 페이로드, 그리고 만료를 함께 보여 줍니다. 넣은 모든 것은 브라우저 안에서 처리되며 밖으로 나가지 않습니다.

**짚어 둘 것은, 서명이 올바른 것과 토큰이 유효한 것은 별개라는 점입니다.** 서명이 통과한다는 것은 그 내용이 발행된 뒤로 고쳐지지 않았음을 증명할 뿐입니다. 실제 인증에서는 `exp`(만료)·`nbf`(유효 개시 시각)·`iss`(발행자)·`aud`(의도한 수신자)가 여러분의 기대와 맞는지도 확인해야 합니다. **구현상의 함정으로 널리 알려진 또 하나는, 어떤 알고리즘으로 검증할지를 토큰 자신의 헤더에 맡겨 버리는 일입니다.** 받아들일 `alg`를 서버가 미리 못 박아 두지 않으면 그 선택을 공격자에게 열어 주는 셈이 됩니다.

검증하는 순서

검증할 JWT를 붙여 넣습니다 점으로 세 부분이 나뉜 문자열입니다.
공개 키를 PEM 형식으로 붙여 넣습니다 **필요한 것은 공개 키이지 비밀 키가 아닙니다.** RS256은 RSA 키를, ES256은 P-256 곡선의 키를 받습니다.
서명을 검증합니다 키와 서명이 맞아떨어지는지 알려 줍니다.
디코딩 결과와 만료를 확인합니다 **서명이 통과한 토큰이라도 기한이 지났다면 써서는 안 됩니다.** 둘 다 보십시오.

더 잘 활용하기 위한 팁

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

이럴 때 쓸 수 있습니다

ID 토큰의 내용을 확인할 때

인증 기반이 발행한 토큰을 그 공개 키와 맞춰 볼 수 있습니다.

키가 틀린 것인지 서명이 깨진 것인지 가릴 때

**검증이 실패할 때 둘 가운데 무엇이 탈인지를 손안에서 가려낼 수 있습니다.**

키 교체를 검증할 때

옛 키와 새 키를 차례로 시험해 보면 갈아타기가 계획대로 굴러갈지 확인할 수 있습니다.

결함의 원인을 좇을 때

인증이 되지 않는다는 보고를 받았을 때, 토큰 자체가 탈인지를 먼저 가려낼 수 있습니다.

JWT 검증 용어

RS256: RSA 키와 SHA-256을 쓰는 서명 방식입니다. **서명은 비밀 키로, 검증은 공개 키로 합니다.**
ES256: P-256 곡선과 SHA-256을 쓰는 서명 방식입니다. 키도 서명도 RSA보다 짧게 끝납니다.
SPKI: 공개 키를 담는 표준 형식입니다. PEM에서는 `-----BEGIN PUBLIC KEY-----`로 시작합니다.
exp: 만료를 알리는 클레임입니다. **서명이 아무리 온전해도 이 시각을 넘긴 토큰은 받아들여서는 안 됩니다.**
nbf: 토큰이 언제부터 쓸 수 있는지를 알리는 클레임입니다. 그 전에는 아직 효력이 없습니다.
알고리즘 혼동: **토큰의 헤더가 지목하는 알고리즘을 그대로 믿고 검증해 버리는 구현의 약점입니다.** 받아들일 방식은 검증하는 쪽에서 못 박아야 합니다.

자주 묻는 질문

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에서 채택이 늘고 있습니다.

모든 여담 보기