JWT 디코더
JWT(JSON Web Token)를 붙여넣으면 헤더와 페이로드를 즉시 디코딩합니다. 만료 시간(exp) 확인 기능도 포함되어 있습니다. 서명 검증은 수행하지 않으며 비밀 키 입력도 필요하지 않습니다.
주요 등록 클레임(Registered Claims) 목록
| 클레임 | 이름 | 설명 |
|---|---|---|
| iss | Issuer(발급자) | 토큰을 발급한 주체를 식별하는 문자열 또는 URL. |
| sub | Subject(주제) | 토큰이 가리키는 대상(보통 사용자 ID). |
| aud | Audience(대상자) | 토큰이 사용될 것으로 예상되는 수신자 또는 API의 식별자. |
| exp | Expiration Time(만료 시간) | 이 시각(Unix 초) 이후에는 토큰을 수락해서는 안 됩니다. |
| nbf | Not Before(유효 시작 시각) | 이 시각(Unix 초) 이전에는 토큰을 수락해서는 안 됩니다. |
| iat | Issued At(발급 시각) | 토큰이 발급된 시각(Unix 초). |
| jti | JWT ID | 토큰을 고유하게 식별하는 ID로, 재전송 공격 방지를 위한 중복 검사 등에 사용됩니다. |
팁
- 입력한 JWT는 브라우저 내 JavaScript로만 처리되며 toolbase.cc 서버로는 전혀 전송되지 않습니다. 토큰에 포함된 개인정보나 인증 정보가 외부로 유출될 걱정이 없습니다.
- JWT는 헤더·페이로드·서명 세 부분이 마침표(.)로 구분된 Base64URL 문자열입니다. 헤더와 페이로드는 누구나 디코딩할 수 있는 평문이므로(Base64는 인코딩이지 암호화가 아닙니다), 비밀번호 같은 민감한 정보를 페이로드에 담아서는 안 됩니다.
- API 요청이 토큰 만료로 401 오류를 반환할 때는 먼저 이 도구로
exp클레임 값을 확인하면 원인 파악이 빨라집니다. - 서명 알고리즘은
alg헤더에서 확인할 수 있습니다.alg: none을 허용하는 구현은 서명 검증을 우회당하는 취약점(JWT의 alg=none 공격)으로 이어지므로, 서버 측에서는 허용 알고리즘을 반드시 명시적으로 제한해야 합니다.
자주 묻는 질문
exp 클레임이 현재 시각보다 과거인 JWT를 거부하고 401 Unauthorized 등의 오류를 반환합니다. 이 경우 리프레시 토큰을 이용한 재발급 등으로 토큰을 다시 받아야 합니다.
여담 ― JWT가 "무상태 인증"을 구현하는 원리
JWT(JSON Web Token)는 2015년 IETF에 의해 RFC 7519로 표준화되었습니다. 기존의 세션 기반 인증에서는 서버가 세션 ID와 사용자 정보를 매핑한 표를 유지해야 했지만, JWT는 사용자 정보 자체를 토큰 안에 담고 서명으로 위변조를 감지하는 방식을 채택했습니다. 이를 통해 서버는 세션 저장소 없이도 인증 상태를 검증할 수 있는 "무상태 인증(stateless authentication)"이 가능해졌으며, 여러 서버에 걸친 분산 시스템이나 마이크로서비스 간 인증에서 널리 채택되고 있습니다.
JWT의 구조는 "헤더.페이로드.서명"의 3부분으로 이루어지며, 각각 Base64URL로 인코딩되어 마침표로 연결됩니다. 중요한 점은 헤더와 페이로드가 암호화가 아니라 단순한 인코딩이라는 것입니다. 누구나 디코딩해서 내용을 읽을 수 있기 때문에, JWT는 "변조되지 않았음을 보장"하는 것이지 "내용을 비밀로 유지"하는 것이 아닙니다. 민감한 정보를 담고 싶다면 암호화를 추가한 JWE(JSON Web Encryption)라는 별도의 사양을 사용해야 합니다.
서명 방식은 크게 송신자와 수신자가 동일한 비밀 키를 공유하는 HMAC 방식(HS256 등)과, 비밀 키로 서명하고 공개 키로 검증하는 공개 키 암호 방식(RS256·ES256 등)으로 나뉩니다. OAuth 2.0과 OpenID Connect의 액세스 토큰·ID 토큰으로 JWT가 채택된 이후, 웹 인증 인프라의 사실상 표준 포맷이 되었습니다.