Secret이 없으므로 서명은 보존됩니다. 편집된 Token은 보통 검증에 실패합니다
도구 설명
JWT 디코더 및 파서 정보
JWT 파서는 JSON Web Token의 Header와 Payload를 디코딩해 alg, typ, 서명 상태, iss, sub, aud, iat, nbf, exp 같은 일반 클레임을 확인합니다.
토큰은 브라우저에서 로컬로 파싱되며, 편집한 Header/Payload는 로컬 HMAC 시크릿으로 다시 서명할 수 있습니다. 토큰은 wetool.site로 업로드되지 않습니다.
JWT Parser 사용 방법
- header.payload.signature 형식의 완전한 JWT를 붙여 넣습니다.
- Decode를 눌러 Header, Payload, 주요 클레임 요약을 확인합니다.
- exp, nbf, iat 값을 확인하세요. 보통 에포크 초입니다.
- HMAC 테스트 토큰은 secret을 입력하면 편집한 Header/Payload를 브라우저에서 로컬로 re-sign합니다.
사용 사례
- 인증 세션 디버깅 중 토큰이 만료되었는지 아직 유효하지 않은지 확인합니다.
- alg, typ, iss, aud, sub가 API 게이트웨이나 백엔드 규약과 맞는지 확인합니다.
- 페이로드 JSON을 보기 좋게 정리해 scope, role, tenant_id 같은 앱 고유 필드를 찾습니다.
- 개발용 토큰 클레임을 수정한 뒤 알려진 HMAC 시크릿으로 로컬 재서명합니다.
JWT 구조, claims, signature 한계
JWT는 보통 Header, Payload, Signature 세 Base64URL 부분로 구성됩니다. Header/Payload 디코딩에는 secret이 필요 없지만 토큰을 신뢰하려면 올바른 key로 서명 검증이 필요합니다.
- Header: 보통 alg와 typ를 포함해 서명 알고리즘과 토큰 종류를 설명합니다.
- Payload: iss, sub, aud, iat, nbf, exp, 앱 고유 필드 같은 클레임을 담습니다.
- Signature: Header/Payload 변조를 막기 위한 값이며, 디코딩만으로 서명이 유효하다는 뜻은 아닙니다.
- 시간 관련 클레임: iat, nbf, exp는 보통 밀리초가 아니라 Unix 초입니다.
JWT 파서 자주 묻는 질문
- JWT 디코딩은 verify와 같은가요?
- 아닙니다. 디코딩은 Header와 Payload를 읽을 뿐입니다. 검증하려면 올바른 비밀 키 또는 공개 키로 서명을 확인해야 합니다.
- 왜 password 없이 payload를 읽을 수 있나요?
- JWT Header와 Payload는 Base64URL 인코딩이지 암호화가 아닙니다. 일반 JWT 페이로드에 비밀 정보를 넣지 마세요.
- exp, iat, nbf는 무엇인가요?
- exp는 만료 시각, iat는 발급 시각, nbf는 유효 시작 시각입니다. 보통 Unix 초로 저장됩니다.
- Payload를 수정한 토큰도 동작하나요?
- 보통 re-sign하지 않으면 동작하지 않습니다. 이 도구는 secret 입력 시 HMAC 테스트 토큰을 로컬에서 다시 sign할 수 있습니다.
- JWT가 업로드되나요?
- 아니요. 디코딩, 편집, HMAC 재서명은 브라우저에서 로컬로 실행되고 wetool.site로 업로드되지 않습니다.
JWT와 세션 쿠키
Session은 보통 서버에 상태를 저장하고 브라우저에는 세션 ID를 줍니다. JWT는 claims를 토큰 안에 담아 서비스 간 전달이 편하지만 expiration, 서명 키, 페이로드 내용 관리가 더 중요합니다.
JWT 서명 검증 및 alg 체크리스트
JWT가 디코딩된다고 곧바로 신뢰할 수 있는 것은 아닙니다. 실제 검증은 알고리즘, 키 출처, issuer, audience, 서명 정책을 고정해 확인해야 합니다.
- 토큰의 alg 헤더만 보고 검증 알고리즘을 선택하지 마세요. 서버는 미리 설정한 허용 목록을 사용해야 합니다.
- alg=none, HS256과 RS256의 혼동, 외부 위치를 가리키는 kid는 고위험 설정으로 취급합니다.
- 이 도구는 확인과 HMAC 테스트 토큰에 유용하지만 운영 환경 검증은 백엔드 또는 인증 게이트웨이에서 해야 합니다.
exp, nbf, iat 시간 디버깅
JWT의 시간 관련 클레임은 보통 Unix 초입니다. 만료 시각이 이상하면 초와 밀리초 혼동, 시계 오차, 시간대 표시를 먼저 확인하세요.
- exp가 current 에포크 초보다 이르면 토큰은 expired이고, nbf가 now보다 늦으면 아직 active가 아닙니다.
- 13자리 밀리초를 초로 해석하면 아주 먼 미래 날짜가 되고, 10자리 초를 밀리초로 해석하면 1970년 근처가 됩니다.
- 서버는 NTP 동기화를 유지하고 작은 시간 오차를 허용하되, 긴 유예 시간으로 설정 실수를 숨기면 안 됩니다.