콘텐츠로 이동

JWT 인증·전달 방식

세션 대신 JWT 기반 stateless 인증. Spring Security CSRF off. 결정 사유는 보안(XSS/CSRF) ↔ 개발비용 트레이드오프.

1. 결정 요약

항목 결정 이유
서버 → 클라 발급 JSON Body 쿠키는 CSRF 위협(CSRF off 상태). 헤더/바디는 HTTPS면 안전, 차이 미미
클라 보관 localStorage 쿠키 HttpOnly는 JS 접근 불가 → 헤더로 못 줌. context에 올려 재조회 최소화
클라 → 서버 전달 헤더 (Authorization) OAuth2/OIDC 표준, 인증 정보는 헤더가 자연스러움
payload { userId, role, iat, exp } 최소화 탈취 대비, 변경 잦은 정보는 API로 별도 조회

2. 보관 방식 트레이드오프

  • 쿠키: XSS 강(HttpOnly), CSRF 취약
  • 헤더/바디(localStorage): CSRF 강, XSS 취약 → CSP 등 추가 방어 필요
  • "쿠키로 받고 헤더로 주기"는 불가 (HttpOnly면 JS가 못 읽음). 받은 채널로 줘야 함

3. 향후 (소셜 로그인 도입 시)

  • Access Token + Refresh Token 도입 → Refresh로 Access 갱신(짧은 만료로 탈취 피해 최소화)
  • 로그아웃/의심 행동 시 Refresh Token 블랙리스트
  • 이때 보안성 재평가 후 쿠키 방식 전환 등 전체 리팩토링 검토

4. 용어

  • withCredentials(크로스 도메인 쿠키 포함), HttpOnly(JS 쿠키 접근 차단), SameSite(CSRF 방지), Secure(HTTPS 전용)

5. 관련