RunToolz iconRunToolz
Welcome to RunToolz!
JWT보안인증

JWT: 그 긴 문자열 안에 실제로 뭐가 있어

JSON Web Token 디코딩. 어떻게 작동하고, 뭘 포함하고, 흔한 보안 실수.

RunToolz Team2026년 1월 26일5 min read

인증 시스템에서 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U 같은 문자열을 봐.

그게 뭐야? JWT야—점으로 구분된 세 개의 Base64 인코딩 덩어리. 특별한 키 없이도 읽을 수 있어.

세 부분

헤더: 알고리즘과 토큰 타입

{"alg": "HS256", "typ": "JWT"}

페이로드: 실제 데이터 (클레임)

{"sub": "1234567890", "name": "John", "iat": 1516239022}

서명: 변조되지 않았다는 검증

직접 사용해 보시겠어요?JWT 디코딩

JWT는 암호화가 아니야

이게 큰 거야. 누구나 JWT를 디코딩해서 내용을 읽을 수 있어. Base64는 인코딩이지 암호화가 아니야.

JWT에 비밀을 넣지 마. 사용자 ID, 권한, 만료 시간—괜찮아. 비밀번호, 신용카드, 비공개 데이터—절대 안 돼.

표준 클레임

iss — 발급자. 이 토큰을 누가 만들었는지.

sub — 주체. 보통 사용자 ID.

exp — 만료. 토큰이 무효가 되는 유닉스 타임스탬프.

iat — 발급 시각. 토큰이 만들어진 시각.

aud — 대상. 이 토큰을 누가 받아야 하는지.

커스텀 클레임도 작동해. 애플리케이션이 필요한 데이터를 뭐든 추가해.

서명이 작동하는 법

서명은 토큰이 수정되지 않았음을 증명해.

서버가 토큰 생성 → 비밀 키로 서명 → 클라이언트에 전송. 클라이언트가 토큰 다시 전송 → 서버가 서명 검증 → 내용 신뢰.

누가 페이로드를 바꾸면 서명이 일치하지 않아. 서버가 거부해.

하지만 서버는 서명을 검증해야 해. 검증 없는 JWT는 보안 쇼야.

흔한 보안 실수

서명 검증 안 함. 어떤 코드는 서명 확인 없이 JWT를 디코딩해. 누구나 토큰을 위조할 수 있어.

약한 비밀 사용. secret123은 비밀이 아니야. 길고 무작위 문자열 써.

만료 무시. 항상 exp를 확인해. 토큰은 짧은 수명을 가져야 해.

알고리즘 혼란. alg 필드가 검증 방법을 말해. 공격자가 none으로 설정해서 코드가 헤더를 신뢰하면 검증을 건너뛸 수 있어.

민감한 데이터 저장. 토큰을 가진 누구나 페이로드를 읽을 수 있어. 비밀은 서버 측에 유지해.

JWT를 써야 할 때

무상태 인증. 서버가 세션을 저장할 필요 없어. 토큰이 필요한 모든 걸 포함해.

마이크로서비스. 서비스가 인증 서버를 호출하지 않고 토큰을 검증할 수 있어.

싱글 사인온. 도메인 간 인증 공유.

JWT를 쓰면 안 될 때

단순한 앱. 세션 쿠키가 더 간단하고 망가뜨리기 어려워.

즉시 무효화 필요. JWT는 만료까지 유효해. 취소하려면 추가 인프라 필요.

큰 페이로드. 모든 요청이 전체 토큰을 실어. 큰 토큰은 더 많은 대역폭을 의미해.

리프레시 토큰

액세스 토큰은 단기적이어야 해 (분에서 시간). 리프레시 토큰은 재인증 없이 새 액세스 토큰을 받아.

리프레시 토큰을 안전하게 저장해. 오래 살고 강력해.


JWT는 편리하지만 주의가 필요해. 뭘 포함하는지 이해하고, 서명을 제대로 검증하고, 짧은 만료를 설정하고, 페이로드에 민감한 데이터를 절대 넣지 마.