서비스 운영 중 마주치는 암호 같은 JWT 토큰
백엔드와 통신하거나 API를 연동하다 보면 eyJhbG...로 시작하는 긴 문자열을 자주 보게 됩니다. 이 문자열이 바로 JWT(JSON Web Token)입니다. 분명 유저 정보가 들어있다고는 하지만, 눈으로는 도무지 읽을 수가 없습니다.
"지금 이 토큰이 만료된 건가?", "사용자 권한이 제대로 들어있나?"를 확인하고 싶을 때마다 매번 복잡한 터미널 명령어를 입력하는 것은 매우 번거로운 일입니다. 오늘은 이 문자열이 어떤 원리로 구성되어 있는지, 그리고 어떻게 하면 가장 쉽고 빠르게 속 내용을 들여다볼 수 있는지 정리해 드립니다.
JWT는 암호화된 것이 아니라 인코딩된 것입니다
가장 많이 오해하는 부분 중 하나가 JWT는 보안을 위해 암호화되어 있다는 생각입니다. 하지만 사실 JWT는 단순히 Base64URL 방식으로 인코딩(진법 변환)되어 있을 뿐입니다.
즉, 누구나 마음만 먹으면 별도의 열쇠 없이도 그 내용을 열어볼 수 있다는 뜻입니다. JWT는 마침표(.)를 기준으로 크게 세 부분으로 나누어 해석해야 합니다.
1. 헤더(Header): 어떤 방식으로 서명했는가?
토큰의 가장 앞부분입니다. 이 토큰을 검증하기 위해 어떤 알고리즘을 사용했는지, 타입은 무엇인지 정의합니다.
- alg: 서명을 만들 때 사용한 알고리즘 (예: HS256, RS256)
- typ: 토큰의 유형 (항상 JWT)
{
"alg": "HS256",
"typ": "JWT"
}
2. 페이로드(Payload): 우리가 진짜 궁금한 데이터
가운데 부분입니다. 로그인한 유저의 ID, 권한, 토큰 만료 시간 같은 실제 정보들이 **클레임(Claim)**이라는 형태로 들어있습니다.
자주 쓰이는 주요 클레임 목록
| 클레임 이름 | 의미 | 설명 |
|---|---|---|
sub |
Subject | 토큰의 주인 (보통 유저 고유 ID) |
iat |
Issued At | 토큰이 발행된 시각 (Unix Timestamp) |
exp |
Expiration | 토큰이 만료되는 시각 |
role |
Role | 사용자의 권한 (관리자, 일반유저 등) |
페이로드는 누구나 디코딩해서 볼 수 있으므로, 비밀번호 같은 민감한 데이터는 절대로 담지 말아야 합니다.
3. 서명(Signature): 이 토큰, 믿어도 될까?
마지막 부분은 보안을 담당합니다. 헤더와 페이로드를 합친 뒤 서버만 알고 있는 비밀 키를 더해서 암호화한 값입니다. 만약 누군가 페이로드의 유저 ID를 몰래 바꾸더라도, 서명 값이 일치하지 않기 때문에 서버는 토큰이 조작되었다고 바로 알아챌 수 있습니다.
복잡한 디코딩, 간편한 도구로 해결해야 합니다
터미널에서 명령어를 입력하며 고생할 필요가 없습니다. 특히 iat나 exp 같은 시간 값은 숫자로 되어 있어 사람이 바로 읽기 매우 어렵습니다.
UtilZip의 JWT 디코더를 사용하면 이 모든 과정을 한 번에 해결할 수 있습니다.
- 즉각적인 파싱: 토큰을 붙여넣기만 하면 헤더와 페이로드를 즉시 분리해 줍니다.
- 스마트 시간 변환: 복잡한 숫자 형태의 만료 시간을 우리가 읽기 편한 날짜 형태로 자동 변환합니다.
- 깔끔하고 직관적인 UI: 광고로 뒤덮인 다른 경쟁 사이트들과 달리, 개발에만 집중할 수 있는 쾌적하고 깔끔한 화면을 제공합니다.
- 철저한 보안: 입력한 데이터는 서버에 저장되지 않고 브라우저 내에서만 처리되므로 안심하고 사용해야 합니다.