헤더의 알고리즘 확인
alg 값이 기대한 방식과 일치하는지 먼저 확인합니다. 운영 환경 문서와 다른 알고리즘이면 검증 실패의 원인이 될 수 있습니다.
JWT 디코더
브라우저 내부 처리
JWT 헤더·페이로드를 확인하고 exp/nbf 등 만료 클레임을 점검하세요. 서명 검증은 지원하지 않습니다.
JWT를 빠르게 점검할 때 보는 포인트
만료 클레임 검토
exp, nbf, iat는 서버 시간 차이와 함께 봐야 합니다. 토큰 자체는 정상인데 시간 동기화 문제로 거부되는 경우도 자주 있습니다.
페이로드 민감도 점검
JWT는 Base64URL로 인코딩된 값이라 내용이 숨겨지지 않습니다. 민감한 개인정보나 비밀 값을 담는 구조인지도 함께 확인하는 편이 좋습니다.
디코딩과 검증은 다릅니다
디코딩만으로 신뢰하면 안 됩니다
토큰 내용을 읽을 수 있다는 것과, 그 토큰이 정상 발급되었다는 것은 다른 문제입니다. 신뢰 판단에는 반드시 서명 검증이 필요합니다.
JWKS URL 검증의 역할
OIDC나 외부 인증 공급자를 쓰는 환경에서는 JWKS로 서명을 대조해야 실제로 해당 발급자가 만든 토큰인지 판단할 수 있습니다.
함께 보면 좋은 도구
JWT 앞뒤로는 JSON 포매터로 구조를 확인하고, Base64 변환기로 관련 인코딩 값을 비교하거나, API 요청 테스트로 재현 요청을 보내는 흐름이 자주 이어집니다.
검증할 때 확인할 점
디코딩과 검증은 다른 일입니다
헤더와 페이로드는 암호화가 아니라 Base64URL 인코딩이라 누구나 읽을 수 있습니다. 서명을 확인하지 않고 페이로드만 읽어 쓰면 공격자가 role을 admin으로 바꾼 토큰을 그대로 신뢰합니다. 라이브러리의 decode()는 서명을 확인하지 않습니다.
헤더의 alg를 믿으면 안 됩니다
alg를 none으로 바꿔 서명을 지우거나, RS256을 HS256으로 바꿔 공개키를 HMAC 비밀키로 쓰게 만드는 공격이 있습니다. 검증할 때 허용 알고리즘을 코드에 못박으세요. 토큰 헤더는 입력값이지 설정이 아닙니다.
페이로드에 비밀을 담지 마세요
누구나 디코딩할 수 있으므로 주민번호, 내부 식별자, 권한 상세를 넣어둔 토큰은 그 자체로 정보 노출입니다. 서버 로그에 토큰이 남는 것도 만료 전까지 쓸 수 있는 자격증명이 남는 것입니다.
사용 순서와 입력 예시 더 보기
JWT를 볼 때 가장 먼저 보는 순서
1. 헤더와 payload를 먼저 열어 구조 확인
alg, typ, iss, aud, sub, exp 같은 핵심 필드가 기대한 시스템과 맞는지 먼저 확인하면 문제 범위를 크게 줄일 수 있습니다.
2. 시간 클레임은 timestamp 도구와 함께 확인
exp, nbf, iat 값은 사람이 읽기 쉬운 시간으로 다시 보고, 서버 clock skew가 있는지도 함께 판단해야 합니다. 이때 timestamp converter와 같이 보는 흐름이 유용합니다.
3. 신뢰 판단은 JWKS 검증까지 진행
읽을 수 있는 토큰과 신뢰할 수 있는 토큰은 다릅니다. 외부 issuer 환경이라면 JWKS URL을 사용해 실제 서명 검증까지 확인하는 편이 안전합니다.