JWT 디코더 및 검증기
JSON Web Token을 붙여 넣고 서버가 읽어야 하는 방식으로 읽으세요. 헤더와 페이로드는 읽기 쉬운 JSON으로 디코딩되고, 시간 클레임은 타임라인으로 그려집니다 — 발급, 유효 시작, 만료, 만료됨. 그리고 HS256, HS384, HS512에 대해서는 제공한 비밀값에 대한 실제 서명 검증을 수행합니다. 모든 것이 브라우저에서 일어납니다. 토큰은 자격 증명이며, 이 사이트에서는 자격 증명을 기록이 남는 AI 채팅이나 낯선 사람의 서버에 붙여 넣지 않습니다.
토큰이란 무엇이며, 디코딩은 무엇을 증명하는가
JWT는 점으로 연결된 세 개의 Base64URL 세그먼트입니다. 서명 알고리즘을 명시하는 헤더, 클레임의 페이로드, 그리고 처음 두 부분에 대한 서명입니다. 가운데 세그먼트 — 모두가 읽고 싶어 하는 부분 — 는 암호화가 아니라 인코딩입니다. Base64 디코더는 키 없이도 그것을 엽니다. 그래서 토큰에는 포스터에 인쇄하지 않을 것은 절대 담으면 안 됩니다. 서명이 더하는 것은 출처입니다. 클레임 하나를 편집하면 HMAC가 더 이상 일치하지 않습니다. 검증하는 쪽이 실제로 검증한다면요. 사고 보고서를 채우는 실패란, 검증 없이 디코딩하고 신뢰한 서버, 토큰 스스로 알고리즘을 고르게 한 라이브러리, 복음처럼 받아들여진 "none" 토큰입니다. 이 페이지는 정직한 워크플로를 비춥니다. 모든 것을 디코딩해 읽고, 시계에 대조해 클레임 타임라인을 읽고(과거의 exp는 서명이 아무리 유효해도 죽은 토큰입니다), 알고리즘 경고를 새기고, 그제야 검증합니다 — 로컬에서, 비밀값은 토큰과 같은 브라우저 탭 안에 머문 채로요. 디버깅 중인 비밀값이 설정 파일에서 왔다면, .env 검증기도 그 파일을 전송하지 않고 확인합니다. 대표 글 챗봇에게 비밀을 맡기지 마세요는 이 도구 가족 전체가 왜 브라우저로 옮겨 왔는지 설명합니다.
자주 묻는 질문
운영 토큰을 여기에 붙여 넣어도 안전한가요?
인터넷에서 그렇게 하기 가장 안전한 곳이며, 이 도구가 존재하는 이유입니다. 디코딩은 이 페이지의 코드로, 사용자의 브라우저에서 일어납니다. 토큰은 전송되지도, 저장되지도, 기록되지도 않습니다. 사람들이 실제로 사용하는 대안과 비교해 보세요. 대화를 제3자의 서버에 보관하는 AI 채팅, 그리고 붙여 넣는 모든 것을 서버가 보게 되는 "온라인 JWT 디코더"입니다. 토큰은 만료될 때까지 살아 있는 자격 증명입니다. 붙여 넣은 곳 어디에서든 재생될 수 있습니다. 여기에서는 어디에도 가지 않습니다 — .env 검증기와 같은 로컬 전용 규칙입니다.
누구나 JWT를 디코딩할 수 있다면, 그건 보안 구멍이 아닌가요?
디코딩은 애초에 보호 수단이 아니었기 때문입니다. JWT는 암호화된 진술이 아니라 서명된 진술입니다. 페이로드는 Base64URL — 인코딩 — 이라 토큰을 가진 누구나 읽을 수 있고, 보안은 서명에 있습니다. 서명은 진술이 키 보유자에 의해 발급되었고 변조되지 않았음을 증명합니다. 고전적인 재난은 개발자가 페이로드를 비밀 취급하거나, 서버가 서명을 검증하지 않아 손으로 편집한 페이로드가 그대로 통과하는 것입니다. 글 Base64는 암호화가 아닙니다가 두 경우 모두의 밑에 깔린 인코딩 혼동을 다룹니다.
여기서 HS256은 검증할 수 있는데 RS256 토큰은 왜 안 되나요?
HS256은 대칭입니다. 하나의 공유 비밀값이 서명과 검증을 모두 하므로, 입력한 비밀값을 HMAC로 로컬에서 확인할 수 있습니다. RS256은 비대칭입니다. 개인 키로 서명하고 짝이 되는 공개 키로 검증하는데, 이 페이지가 그것을 요구해야 한다면 — 키 붙여넣기를 권하는 페이지는 결국 유출된 개인 키로 끝나는 습관을 가르칩니다. RS256 토큰은 발급자가 공개한 JWKS로 본인의 코드나 도구에서 검증하고, 개인 키는 이 페이지를 포함해 어떤 웹사이트나 채팅에도 절대 붙여 넣지 마세요.
"alg: none"은 무엇을 뜻하며 왜 빨간 경고인가요?
토큰이 서명되지 않았다고 선언한다는 뜻입니다 — 그리고 그 선언을 존중하는 서버는 누구의 어떤 페이로드든 키 없이 받아들입니다. 실제로 반복된 취약점 부류였습니다. 토큰 자체의 alg 필드를 신뢰한 라이브러리는 관리자 페이로드를 담은 "none" 토큰을 건네받을 수 있었습니다. 경고가 요란한 것은 올바른 대응이 요란하기 때문입니다. none 토큰은 인증되지 않은 데이터이며, 그것을 받아들이는 시스템은 설계상 인증 우회를 안고 있습니다.
서명이 확인됐습니다 — 끝난 건가요?
토큰이 비밀값 보유자에 의해 발행되었고 내용이 변조되지 않았음을 증명했습니다. 당신을 위한 것인지(aud 클레임 확인), 현재 유효한지(위 타임라인이 exp와 nbf를 보여 줍니다), 비밀값 자체가 강한지는 증명하지 못했습니다. "secret" 같은 추측 가능한 비밀값의 HS256은 오프라인 무차별 대입에 무너지고, 그 후에는 누구나 당신의 검증을 통과할 토큰을 발행할 수 있습니다. 검증은 감사의 한 줄이지, 감사 전체가 아닙니다.