동작 방식
JSON 웹 토큰은 점으로 구분된 세 개의 Base64URL 부분(헤더, 페이로드, 서명)으로 이뤄져요. 디코딩은 앞의 두 개만 읽기 때문에 오프라인으로 되고, 누가 발급했는지는 증명하지 않아요. 발급자의 키로 서명을 확인해야 진짜인지 알 수 있고, 서명이 맞아도 만료된 토큰은 거부해야 해요.
header.payload.signature → JSON + 날짜 + 서명 확인
어떤 키를 쓸까요
- HS256 / HS384 / HS512: 공유 비밀키 텍스트를 붙여 넣으세요. 이 키를 가진 사람은 서명도 검증도 할 수 있어요.
- RS256–RS512 / PS256–PS512: PEM(SPKI)이나 JWK 형태의 공개키를 붙여 넣으세요. 개인키는 발급자가 가지고 있어요.
- ES256 / ES384 / ES512: PEM이나 JWK 형태의 EC 공개키를 붙여 넣으세요. 토큰 안의 날(raw) R‖S 서명은 자동으로 변환돼요.
- EdDSA: Base64URL이나 16진수 형태의 32바이트 공개키를 붙여 넣으세요.
- none: 서명이 전혀 없어요. 이런 토큰은 절대 믿으면 안 돼요.
활용 팁
- exp, iat, nbf는 날짜로 보여 주고, 각각 이미 지났는지도 함께 보여 줘요.
- 진짜 액세스 토큰을 붙여 넣으면 네트워크로는 안전하지만, 토큰을 가진 사람은 쓸 수 있어요. 유효기간이 짧은 테스트용 토큰을 쓰세요.
- 모든 처리가 브라우저 안에서 이루어지고, 아무것도 업로드되지 않아요.
계산 기준과 출처
- JSON 웹 토큰(JWT): RFC 7519, JWS 서명: RFC 7515
- 알고리즘(HS/RS/PS/ES): RFC 7518, EdDSA: RFC 8032
- Base64URL: RFC 4648
최종 검토 2026년 10월 12일
자주 묻는 질문
디코딩하면 뭘 증명하나요?
진짜인지는 아무것도 증명하지 않아요. 디코딩은 누구나 위조할 수 있는 헤더와 페이로드를 읽을 뿐이에요. 발급자의 키로 서명을 확인해야 진짜 토큰인지 알 수 있어요.
어떤 알고리즘을 검증할 수 있나요?
공유 비밀키 쓰는 HMAC(HS256/384/512), PEM·JWK 공개키 쓰는 RSA(RS/PS)와 ECDSA(ES256/384/512), 날(raw) 공개키 쓰는 EdDSA(Ed25519)를 검증해요. alg가 none인 토큰은 서명이 없어서 절대 믿으면 안 돼요.
유효한 토큰인데 서버에서 거부하는 이유는 뭔가요?
대부분 exp 만료, audience·issuer 불일치, 서명 측과 서버의 시계 어긋남 때문이에요. 이 페이지에서 날짜 클레임을 하나씩 보여 주니 어느 게 문제인지 찾을 수 있어요.
진짜 토큰을 여기에 붙여 넣어도 안전한가요?
이 페이지는 완전 오프라인이라 어디에도 전송되지 않지만, 토큰을 가진 사람은 만료 전까지 쓸 수 있어요. 실제 서비스 토큰보다 유효기간이 짧은 테스트용 토큰을 쓰세요.