JWT 저장 & 통신 방식

JWT 저장 & 통신 방식 정리표

저장 방식 전송 방식 장점 단점 주요 위험요소 권장 상황

localStorage	Authorization 헤더 (Bearer ${token})	- 구현 간단- 새로고침 유지- 브라우저간 공유 가능 (같은 도메인)	❌ XSS 취약❌ 자바스크립트 접근 가능	XSS	개인용 앱, 내부 시스템, MVP
sessionStorage	Authorization 헤더 (Bearer ${token})	- XSS 대비 약간 유리 (탭마다 분리)- 새로고침만 날아감	❌ 새로고침 시 날아감❌ XSS 여전히 가능	XSS	인증 테스트/임시 보안 필요한 상황
HttpOnly 쿠키	자동으로 쿠키 전송 (withCredentials: true)	- XSS로부터 안전- 자동 전송으로 UX 우수	❌ CSRF 방어 필요❌ 쿠키 설정 복잡❌ 도메인 제약	CSRF	실서비스, 민감 데이터 앱, 금융 서비스
쿠키 + SameSite=Strict	자동 쿠키 전송	- CSRF 자동 방지됨- 외부 요청 차단	❌ 일부 브라우저 호환성 문제❌ UX 제약 가능성	CSRF 낮음	보안 우선 앱 (은행, 의료 등)
IndexedDB or WebCrypto	커스텀	- 높은 보안 (암호화 저장 가능)- 컨트롤 유연함	❌ 구현 복잡도 높음❌ 브라우저 간 접근 어려움	구현 실수	보안에 매우 민감한 시스템

---

통신 방식 특징 비교

방식 특징 예시

Authorization 헤더	- 프론트에서 수동으로 넣음- REST API 호출에 일반적	Bearer ${token}
withCredentials: true	- 쿠키 전송 자동 처리- CSRF 방어 병행 필요	브라우저 쿠키 자동 전송
쿠키 + SameSite 정책	- 외부 사이트에서 쿠키 전송 제한 가능- CSRF 방지	SameSite=Strict, Lax, None
토큰 쿼리 파라미터 (?token=)	❌ 비추. URL에 노출되어 위험성 큼	테스트용에만 사용 가능

---

 핵심 요약

1. 보안성 높은 방식
   • HttpOnly + Secure 쿠키 + SameSite
   • Refresh Token 전략 + 짧은 Access Token 수명 조합
2. 개발 편의성 높은 방식
   • localStorage에 JWT 저장 + Authorization 헤더 전송
3. 피해야 할 방식
   • URL에 토큰 노출 (?token=...)
   • 쿠키를 쓰면서 CSRF 방어 안 하는 것

---

대안 및 보완 전략

위험 요소 보완책

XSS	- HttpOnly 쿠키 사용- CSP(Content Security Policy) 설정
CSRF	- SameSite=Strict 쿠키- CSRF 토큰 검증
토큰 탈취	- Access Token은 짧게(15분)- Refresh Token은 HttpOnly 쿠키에 저장

---

추천 전략 (실서비스 기준)

프론트/백 분리 환경에서 안전한 JWT 인증 흐름

1. Access Token: 짧게 (15~30분), Authorization 헤더로 전송
2. Refresh Token: HttpOnly + Secure + SameSite=Strict 쿠키에 저장
3. 백엔드:
   • 모든 민감 요청은 Access Token 검사
   • 만료 시 Refresh Token으로 새 Access Token 재발급
4. CSRF 방어: SameSite + CSRF Token 병행