Session VS JWT

Session

1. 클라이언트에서 서버에 로그인 요청
2. 서버는 DB에 저장된 유저의 인증정보를 확인
3. 유효한 요청이었다면 해당 유저에 대한 세션을 생성하고, 이를 서버 메모리에 저장
4. 쿠키(매개체)를 통해 해당 유저의 SessionId를 클라이언트에 전달
5. 클라이언트에 SessionId가 저장
6. 클라이언트에서 서버로 API 요청 할때, 쿠키(매개체)에 SessionId가 함께 전달
7. 서버는 전달받은 SessionId를 기반으로 유저의 세션 데이터를 조회
8. 세션이 유효하다면, 유저의 요청에 대한 응답 데이터를 전송

Session의 장단점
장점:
세션 제어: 세션 탈취 시 서버에서 즉시 세션을 무효화하여 신속하게 보안 대응 가능
단점:
- CORS 이슈: 쿠키 기반 동작으로 다른 도메인 간 요청에 제약이 존재
- 서버 의존성: 세션 정보가 서버에 저장되어 서버 장애 시 정보 손실 가능성 있음
- CSRF 취약점: 쿠키 기반 인증은 추가 보안 조치 없이 CSRF 공격에 취약

• 일반적으로 cross-origin(도메인이 다르면)일 경우, 브라우저는 쿠키를 보내지 않음
• Client에서 "Credentials" 설정을 통해 쿠키를 담을 수 있음.

JWT(Javascript Web Token)

1. 클라이언트가 인증정보를 담아 서버에 로그인 요청
2. 서버는 DB에 저장된 유저의 인증정보를 확인
3. 인증에 성공했다면, 서버는 유저에 대한 권한정보를 서버의 비밀키와 함께 토큰을 생성
4. 서버는 Authorization 헤더에 토큰을 담아 클라이언트에 전달
5. 클라이언트는 전달받은 토큰을 브라우저의 세션 스토리지 or 로컬스토리지 에 저장
6. 클라이언트가 서버로 API 요청할때, Authorization 헤더를 통해 토큰이 함께 전달
7. 서버는 전달받은 토큰을 서버의 비밀키로 검증. 이를 통해, 토큰이 위조되었는지 토큰의 유효기간이 지나지 않았는지 등을 확인할 수 있습니다
8. 토큰이 유효하다면, 유저의 요청에 대한 응답 데이터를 전송

JWT의 장단점

장점:

• 무상태성(Stateless): 서버가 클라이언트 상태를 저장할 필요가 없어 서버 자원을 효율적으로 사용하고 확장성이 뛰어남
• 교차 도메인 지원: Authorization 헤더를 사용하므로 CORS 문제에서 비교적 자유롭고 다양한 플랫폼에서 활용 가능함
• 분산 시스템 적합: 서버 간 인증 정보 공유가 필요 없어 마이크로서비스 아키텍처에 적합함
  
  단점:
• 서버 제어 제한: 발급된 토큰은 서버에서 강제로 만료시키기 어려워 보안 사고 발생 시 대응이 제한적임
• 저장소 노출 위험: 로컬/세션 스토리지에 저장 시 XSS 공격에 취약하고, 쿠키 저장 시 CSRF 공격 위험이 있음

항목	쿠키 (Cookie)	Web Storage (localStorage / sessionStorage)
자동 전송	✅ 요청 시 자동 전송	❌ 수동 헤더 설정 필요
보안 속성	HttpOnly, Secure, SameSite 설정 가능	❌ 없음 (XSS에 취약)
XSS 대응력	✅ HttpOnly 사용 시 안전	❌ 매우 취약
CSRF 대응력	❌ 기본은 취약 → SameSite 필수	✅ 안전 (헤더 기반 요청이므로)
사용 용도	인증 토큰 저장에 적합	일반 데이터 저장용, 인증은 비권장

예상 면접 질문 List:

• JWT 방식에서 토큰 탈취가 발생했을 때 대응 방법은 무엇인가요?
  - 즉시 무효화가 어렵다 (stateless 특성 때문)
  • Access Token 짧은 만료시간 설정, Refresh Token을 통해 관리

Reference

https://kindjjee.tistory.com/139#hELLO