HTTP가 이전 요청을 기억하지 못하는 무상태성 때문에 로그인 상태를 매번 따로 전달해야 하는 문제에서 출발해, 서버 세션과 JWT 인증의 동작 원리와 트레이드오프를 비교한다. 각 방식의 저장·검증 비용과 보안 특성을 짚고 현실적인 절충안까지 이어간다.
핵심 포인트- 매 요청 ID·비밀번호 전송은 탈취 위험이 커 별도 상태 전달이 필요 — 서버 세션은 세션 저장소에 사용자 정보를 두고 쿠키의 세션 ID로 식별하지만 요청마다 저장소 조회가 필요하고 서버·저장소가 늘면 관리가 복잡
- JWT는 헤더·페이로드·서명 구조로 서버 비밀키로 위변조를 검증해 세션 조회 없이 분산 환경에 유리하나, 유출된 토큰을 즉시 무효화하기 어려움
- 쿠키의 자동 전송이 CSRF를 부를 수 있어 SameSite·Secure·HttpOnly·경로/도메인 제한·CSRF 토큰으로 방어, JWT를 로컬 스토리지에 두면 XSS에 노출되고 HttpOnly 쿠키는 읽기를 막는 대신 CSRF 방어가 별도로 필요
- 수명이 짧은 액세스 토큰은 저장소 조회 없이 검증하되 노출 시간을 줄이고, 서버에 보관하는 리프레시 토큰은 필요 시 폐기 가능 — 세션과 순수 JWT의 단점을 절충
왜 읽나인증 방식을 고르는 웹 개발자에게 세션·JWT·쿠키/스토리지·리프레시 토큰의 확장성과 보안 트레이드오프를 10분에 정리해주는 입문 톡.