JWT 인증 완전 가이드: 구조·검증·만료·보안 실수 7가지

가이드 · 2026.07.14 최종 확인

JWT(JSON Web Token)는 현대 웹·모바일 API 인증의 사실상 표준입니다. 그런데 "토큰이 세 부분으로 나뉘어 있다"는 것만 알고, 서명이 실제로 무엇을 보장하는지, 왜 만료 시간을 짧게 잡아야 하는지는 모르고 쓰는 경우가 많습니다. 이 가이드는 JWT의 구조부터 실무 보안 실수까지 한 번에 정리합니다.

1. JWT의 3단 구조

JWT는 점(.)으로 구분된 세 부분 Header.Payload.Signature로 구성되며, 각 부분은 URL-safe Base64로 인코딩됩니다.

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0IiwiZXhwIjoxNzUyNDU2MDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

• Header: 서명 알고리즘(alg)과 토큰 타입(typ)을 담은 JSON. 예: {"alg":"HS256","typ":"JWT"}
• Payload: 클레임(claim)이라 불리는 실제 데이터. sub(주체), exp(만료), iat(발급시각) 등 표준 클레임과 커스텀 클레임을 포함합니다.
• Signature: Header와 Payload를 합친 값을 비밀키(또는 개인키)로 서명한 값. 이 값이 있어야 토큰 위변조를 감지할 수 있습니다.

토큰 내용을 직접 열어보려면 JWT 디코더에 붙여넣으면 세 부분을 자동으로 분리해 사람이 읽을 수 있는 형태로 보여줍니다.

2. Header·Payload는 "암호화"가 아니라 "인코딩"

가장 중요한 오해입니다. Base64는 암호화가 아니라 인코딩이므로 누구나 디코딩해서 내용을 읽을 수 있습니다. JWT가 안전한 이유는 내용을 숨겨서가 아니라, Signature로 위변조를 감지할 수 있기 때문입니다. 즉 비밀번호, 주민번호 같은 민감 정보를 Payload에 그대로 넣으면 안 됩니다. Base64 자체의 인코딩·디코딩 원리는 Base64 디코더에서 직접 실험해볼 수 있습니다.

3. 서명 검증의 원리: HMAC vs RSA

서명 알고리즘은 크게 대칭키(HS256 등, HMAC 기반)와 비대칭키(RS256 등, RSA 기반) 두 계열로 나뉩니다. HMAC 방식은 서버가 발급과 검증에 같은 비밀키를 사용하므로 키가 유출되면 누구나 위조 토큰을 만들 수 있습니다. HMAC 서명이 어떻게 계산되는지는 HMAC 생성기로 직접 확인할 수 있습니다. RSA 방식은 발급 서버만 개인키를 갖고, 검증 서버들은 공개키만 배포받아 검증하므로 여러 서비스가 토큰을 검증해야 하는 마이크로서비스 구조에 적합합니다.

4. 만료(exp) 처리: 왜 짧게 잡아야 하는가

JWT는 발급 후 서버가 강제로 무효화하기 어렵습니다(세션처럼 서버에 상태를 저장하지 않는 것이 JWT의 장점이자 단점). 그래서 탈취당했을 때 피해를 줄이는 유일한 방법이 짧은 만료 시간입니다. 실무에서는 Access Token은 15분~1시간, Refresh Token은 며칠~몇 주로 분리해서, Access Token이 만료되면 Refresh Token으로 재발급받는 구조를 씁니다. exp 클레임은 유닉스 타임스탬프(초 단위)로 저장되므로, 특정 exp 값이 실제 어느 시각인지 확인하려면 타임스탬프 변환기로 바로 변환해보세요.

5. 실무에서 자주 발생하는 보안 실수 7가지

iss·aud 클레임으로 토큰 오남용 막기

exp만큼 자주 간과되는 것이 iss(발급자)와 aud(대상자) 클레임입니다. 여러 서비스가 같은 인증 서버에서 발급받은 토큰을 공유하는 구조라면, A 서비스용으로 발급된 토큰을 B 서비스가 검증 없이 그대로 받아들이는 실수가 생길 수 있습니다. 검증 로직에서 iss가 신뢰하는 발급자인지, aud가 자신을 가리키는지까지 확인해야 "토큰은 유효하지만 원래 이 서비스용이 아니었던" 케이스를 막을 수 있습니다.

자주 묻는 질문