JWT와 토큰 인증
디코딩, 서명 검증, 인가의 차이
발생 상황
API가 JWT의 sub·role 값을 사용하면서 서명 또는 발급자·대상·유효기간 검증을 빠뜨리면 변조나 잘못된 토큰 수용 문제가 발생합니다.
주요 유형
서명 검증 누락, none 알고리즘 수용, 약한 HMAC 키, 알고리즘 혼동, 키 선택 검증 결함을 구분합니다. 모든 JWT 문제가 같은 변조 방식으로 해결되는 것은 아닙니다.
분석할 때 주의할 점
Base64url 디코딩은 서명 검증도 복호화도 아닙니다. 토큰의 alg를 그대로 신뢰하지 마세요. 서명이 유효해도 현재 사용자가 요청한 자원에 접근할 권한이 있는지는 별도 확인해야 합니다.
대응 방안
검증 라이브러리에서 알고리즘을 서버 설정으로 고정합니다. 서명·exp·nbf·iss·aud를 검증하고 강한 키와 회전 정책을 사용합니다. 사용자 역할 변경과 계정 폐기 시 기존 토큰 처리 정책도 정의합니다.
자주 놓치는 부분과 특이사항
일반적인 서명 JWT의 Payload는 암호화되어 있지 않습니다. 민감 정보를 담지 않으며 토큰을 URL 쿼리에 넣으면 로그·브라우저 기록 등에 남을 수 있습니다.
JWT · 서명과 권한 더 알아보기
이 실습은 Header.Payload.Signature로 구성된 JWS Compact 형식의 JWT를 사용합니다. Payload의 Base64url 디코딩은 복호화가 아닙니다. JWT는 암호화된 JWE 형식으로도 표현할 수 있습니다. 권한을 신뢰하려면 서명과 허용 알고리즘부터 확인해야 합니다.
서명을 검증하지 않고 role을 읽거나 alg=none을 신뢰하는 결함, 약한 HMAC 키, 알고리즘 혼동은 서로 다른 문제입니다. exp·nbf·iss·aud 검증도 필요하며, 서명이 유효하다는 사실만으로 모든 자원에 대한 권한이 생기지는 않습니다.
요청과 구현 비교
19번 · 유출된 HMAC 키
체험 계정 JWT를 디코딩해 클레임을 확인한 다음, 실습 사이트의 클라이언트 설정 요청에서 노출된 전용 서명키를 찾습니다. Payload만 고치면 서명이 깨집니다. 같은 키로 새 JWT를 서명해 쿠키에 넣은 후 관리자 API의 응답을 비교하세요. 실제 서비스의 비밀키는 클라이언트에 두면 안 되며, 이 문제의 키는 실습 세션에만 묶여 있습니다.
서명된 토큰의 거부 조건
이 실습은 서명된 JWT(JWS)입니다. 인가 전에 서명과 허용 알고리즘, 만료, 발급자·대상, 필요한 클레임을 함께 검증해야 합니다. 키가 유출되면 키 회전과 기존 토큰 무효화 정책까지 필요합니다.
검증 요청 기대 결과
유효한 체험 토큰 일반 사용자 접근 허용
페이로드만 수정 서명 불일치로 거부
만료된 토큰 만료로 거부
다른 발급자/대상 출처 정책에 따라 거부
유효한 관리자 토큰 관리자 기능 허용적용 조건과 재검증
19번은 키 유출 시나리오
19번은 서명 검증을 끄는 문제가 아닙니다. 실습용 서명키가 노출되어 공격자가 유효한 서명을 만들 수 있는 조건입니다. 운영 환경에서는 키를 폐기·회전하고 기존 토큰의 처리 정책을 정해야 합니다. 토큰 종류별 필수 클레임과 발급자·대상 검증 규칙도 분리합니다.