JWT 디코더란?
JWT 디코더는 JSON Web Token 문자열을 사람이 읽을 수 있는 Header와 Payload로 풀어보는 도구입니다. JWT는 웹 로그인, API 인증, OAuth·OpenID Connect 환경 등에서 사용자나 애플리케이션에 관한 정보를 클레임(claim) 형태로 전달할 때 자주 사용됩니다.
일반적인 서명 JWT는
Header.Payload.Signature처럼 점(.)으로 구분된 3개의 구간으로 보입니다. Header와 Payload는 Base64URL 형식으로 인코딩되어 있기 때문에 비밀키가 없어도 내용을 읽을 수 있습니다. 따라서 JWT를 디코딩할 수 있다는 사실만으로 해당 토큰이 정상 발급되었거나 변조되지 않았다고 판단하면 안 됩니다.JWT Header, Payload, Signature의 차이
- Header:
alg,typ,kid처럼 서명 방식이나 키 식별 정보를 담을 수 있습니다. - Payload: 사용자 ID, 권한, 발급자, 만료 시간 등 실제 클레임이 들어갑니다.
- Signature: Header와 Payload가 발급 이후 변경되지 않았는지 확인하는 데 사용됩니다. 실제 검증에는 서버가 신뢰하는 키와 검증 절차가 필요합니다.
exp, nbf, iat는 어떻게 읽나요?
JWT에서 시간 관련 클레임은 보통 Unix timestamp와 비슷한 NumericDate 값으로 저장됩니다. 값은 1970년 1월 1일 00:00:00 UTC부터 경과한 초를 나타냅니다. 이 디코더는 숫자를 한국 로컬 시간과 UTC 시간으로 함께 바꿔 표시합니다.
exp: 이 시간 이후에는 토큰을 받아들이지 않아야 하는 만료 시간입니다.nbf: 이 시간 전에는 토큰을 받아들이지 않아야 하는 사용 시작 시간입니다.iat: 토큰이 발급된 시간을 나타냅니다.
JWT 디코딩과 JWT 검증은 다릅니다
JWT 디코딩은 Base64URL 데이터를 읽는 작업이고, JWT 검증은 서명 알고리즘, 키, 발급자(
iss), 수신 대상(aud), 만료 시간 등의 정책을 실제 애플리케이션 기준으로 확인하는 작업입니다. 브라우저에서 Payload가 정상적으로 보이더라도 서명이 틀렸거나 공격자가 임의로 만든 토큰일 수 있습니다.JWS와 JWE의 차이
JWT는 서명 또는 MAC이 적용된 JWS 구조로 표현될 수도 있고, 암호화된 JWE 구조로 표현될 수도 있습니다. 이 도구는 3개 구간이면 일반적인 JWS 형태로, 5개 구간이면 JWE 형태로 구분합니다. JWE의 Payload는 암호화되어 있으므로 복호화 키가 없는 단순 디코더에서는 내용을 읽을 수 없습니다.
JWT를 확인할 때 주의할 점
- JWT Payload에 비밀번호, 주민등록번호, 결제정보 같은 민감정보를 넣지 않는 것이 좋습니다.
- 디코딩 결과가 정상이어도 실제 인증 처리에서는 반드시 서버 측 서명과 클레임 정책을 검증해야 합니다.
alg: none또는 예상하지 않은 알고리즘이 나타나면 서버의 허용 알고리즘 설정을 확인해야 합니다.- 운영 환경 토큰을 외부 사이트에 붙여넣을 때는 토큰이 서버로 전송되는지 확인하는 것이 안전합니다. 이 페이지의 구현은 브라우저에서만 디코딩합니다.
자주 묻는 질문
- Q. JWT를 디코딩하면 비밀키도 알 수 있나요?A. 아니요. Header와 Payload를 읽는 것만으로 서명에 사용한 비밀키나 개인키를 알아낼 수는 없습니다.
- Q. 만료되지 않았다고 표시되면 유효한 토큰인가요?A. 아닙니다. 이 도구의 만료 상태는 exp·nbf 같은 시간 클레임만 해석한 것입니다. 실제 유효성은 서명, 발급자, audience 등 서버의 검증 조건까지 통과해야 판단할 수 있습니다.
- Q. Bearer eyJ... 형식도 붙여넣을 수 있나요?A. 가능합니다. 입력값 앞의 Bearer 접두사와 공백은 자동으로 제거한 뒤 JWT 본문을 디코딩합니다.
- Q. 5개 구간으로 된 JWT는 왜 Payload가 보이지 않나요?A. 5개 구간은 JWE처럼 암호화된 구조일 수 있습니다. 암호화된 Payload는 Base64URL 디코딩만으로 읽을 수 없고 적절한 복호화 키가 필요합니다.
