뉴스피드 프로젝트
Session vs JWT
Session 기반 인증
서버에 사용자 상태 저장(stateful) → 클라이언트엔 세션ID만 쿠키로 전달(JSESSIONID)
사용자가 요청을 보낼 때마다 쿠키에 담긴 세션ID로 서버가 상태를 조회해 인증을 처리
장점
서버에서 세션을 무효화하면 즉시 로그아웃 가능
민감정보는 서버에만 저장되어 노출 위험이 적음
단점
서버 확장 시 세션 공유(Sticky Session, Redis 등) 필요
쿠키 기반이라 CSRF 방어가 필수
JWT 기반 인증
서버가 상태를 저장 X(stateless) → 토큰 자체에 사용자 정보와 만료 시간을 담아 서명
클라이언트는 토큰을 보관하고 요청 시 헤더에 실어 보냄 → 서버는 서명과 만료만 검증
장점
서버 확장에 유리 (무상태)
게이트웨이, 외부 서비스 등 다양한 환경에서 검증 가능
단점
토큰 탈취 시 만료 전까지 무효화 어려움
토큰 크기가 커질 수 있어 네트워크 비용 증가
보안 관점 비교
| 구분 | 세션 기반 인증 | JWT 기반 인증 |
| CSRF | 쿠키 자동 전송으로 취약 → SameSite, CSRF 토큰 필요 | 헤더 전송 시 안전, Refresh Token을 쿠키에 둘 경우 대책 필요 |
| XSS | HttpOnly 쿠키로 JS 접근 차단 가능 | localStorage 보관 시 XSS 위험 → HttpOnly 쿠키 사용 권장 |
| 로그아웃 처리 | 서버에서 세션 삭제로 즉시 반영 | 블랙리스트나 Refresh Token 저장소 무효화 필요 |
| 탈취 대응 | 서버에서 세션 무효화로 즉시 차단 가능 | 무상태 특성상 즉시 차단 어려움, 짧은 만료·로테이션 필요 |
※CSRF, XSS
CSRF
로그인된 사용자의 쿠키를 악용해, 사용자가 의도하지 않은 요청을 보내는 공격
대응 방법: CSRF 토큰, SameSite 쿠키 설정
XSS
웹 페이지에 악성 스크립트를 삽입해 브라우저에서 실행시키는 공격
대응 방법: 입력값 필터링, HttpOnly 쿠키, CSP 설정
상황별 선택 가이드
| 상황 | 인증 방식 | 이유 |
| 단일 서버, 즉시 로그아웃 필요 | 세션 | 서버에서 바로 무효화 가능 |
| 무상태 확장, 다양한 클라이언트 지원 | JWT | 서버 간 상태 공유 불필요 |
| 강제 만료·권한 변경이 잦음 | 세션 또는 JWT+Refresh 저장소 | 실시간 반영 필요 |
| API 게이트웨이·외부 서비스 검증 | JWT | 키만 공유하면 어디서나 검증 가능 |
오늘은 JWT를 포함해 다양한 내용을 찾아보고 정리하는 시간을 가졌다. 코딩에 집중하다 보면 그때그때의 기록을 남기는 데 소홀해지는 경우가 많다는 걸 새삼 느꼈다. 트러블슈팅 과정, 내가 공부하고 찾아본 내용, 프로젝트를 진행하며 팀원들과 나눈 회의록 등 문서화해두면 나중에 큰 도움이 되는 것들이 참 많다. 튜터님의 피드백도 바로바로 정리하고 팀원들과 공유하며 반영하려 했지만, 당장 눈앞의 코드에 집중하다 보니 놓친 부분이 많았다는 걸 깨달았다. 하루를 마무리하며 모든 내용을 정리하려고 하면 막막함과 어려움이 드는 것도 당연한 일이다. 하지만 이런 작은 인식 하나가 앞으로의 작업 방식에 큰 변화를 줄 수 있다고 믿는다.