Decode JWT: 빠르게 읽되, 절대 맹신하지 마세요
JWT는 header.payload.signature 세 파트로 구성됩니다. 디코딩은 내용을 읽는 것이고, 검증은 서명이 올바른지 확인하는 것입니다. 디코딩만으로는 토큰이 유효하다는 뜻이 아닙니다. 이 차이를 놓치면 만료되었거나 위조된 토큰을 믿는 실수가 생깁니다.
1) JWT 구조 이해하기
- Header: 알고리즘(
alg), 타입(typ) 등 메타 정보 - Payload: 실제 클레임(사용자 정보, 만료 시간 등)
- Signature: 서명. 위조 방지에 핵심
2) 디코딩이 유용한 상황
- 만료(
exp) 확인 - issuer/audience 확인
- 개발/디버깅 중 claim 확인
- 토큰 구조가 맞는지 빠르게 검토
- 인증 서버와 클라이언트 간 클레임 차이 확인
3) 주의할 점
- 디코딩은 서명 검증이 아닙니다.
- 운영 토큰을 외부 도구에 붙여넣는 것은 피하세요.
- payload에 개인정보를 넣는 설계는 지양하세요.
alg값을 신뢰하기 전에 서버 검증 로직을 먼저 확인하세요.
4) 실무 체크리스트
exp가 초 단위인지 확인iss,aud가 기대값과 일치하는지 확인- 민감한 claim이 포함되어 있지 않은지 점검
5) 바로 써보기
JWT Decoder 툴에서 header/payload를 확인하고, 만료와 claim을 빠르게 점검하세요. 단, 검증은 서버 로직에서 반드시 수행해야 합니다.
6) 검증 체크리스트
alg가 기대값인지 확인exp가 만료되지 않았는지 확인iss,aud가 일치하는지 확인- 서명 검증 로직이 서버에 있는지 확인
7) 키 관리 팁
- 시크릿은 환경 변수로 관리하고 코드에 직접 넣지 않습니다.
- 키 회전 정책을 마련하고 만료된 키는 폐기합니다.
- 여러 발급자를 쓰면
kid와 JWK 갱신 정책도 점검하세요.
8) 자주 보는 문제
가장 흔한 문제는 exp를 밀리초로 착각하거나, aud 검증을 생략하거나, 디코딩 결과만 보고 "토큰이 정상"이라고 결론 내리는 것입니다. 또 어떤 팀은 payload에 이메일, 이름, 권한 목록을 과도하게 넣어 토큰이 커지고 보안 부담도 커집니다. JWT는 서명된 전달 형식이지 비밀 저장소가 아닙니다.
9) 디버깅 순서
- 토큰이 세 파트로 나뉘는지 확인
- header의
alg,kid,typ확인 - payload의
iss,aud,sub,exp,nbf확인 - 서버 검증 설정과 실제 기대값 대조
- 시계 차이(clock skew) 허용 범위 확인
10) 체크리스트
- 운영 토큰을 외부 도구에 넣지 않았는가?
- 서명 검증 없이 인증 로직을 실행하지 않았는가?
- 만료 시간 단위를 정확히 해석했는가?
- 토큰에 과도한 개인정보를 넣지 않았는가?
11) 운영 팁
문제가 반복된다면 "왜 토큰을 읽어야 하는가"를 먼저 분리하는 것이 좋습니다. 단순 디버깅이면 로컬 테스트 토큰으로 충분하고, 실제 인증 문제라면 발급 서버와 검증 서버의 설정 차이를 비교하는 편이 더 정확합니다.