서버가 사용자 정보를 서버의 메모리 또는 저장소에 저장하고, 클라이언트에게는 Session ID를 발급하여 쿠키에 담아 전달함.
클라이언트는 매 요청마다 Session ID를 보내고, 서버는 이걸 조회해서 인증 여부를 판단함.
서버가 로그인 시 사용자 정보를 기반으로 JWT 토큰을 발급하고, 클라이언트는 이 토큰을 저장했다가 요청 시마다 HTTP 헤더에 포함시켜 보냄.
서버는 해당 토큰이 유효한지 검증만 하면 됨, 사용자 상태를 저장할 필요 없음.
사용자가 로그인하면 서버는 세션 ID를 생성하고 사용자 정보와 함께 저장
클라이언트는 이 세션 ID를 쿠키에 저장
이후 요청 시마다 쿠키로 세션 ID 전송
서버가 세션 ID에 해당하는 사용자 정보를 조회
사용자가 로그인하면 서버가 JWT 토큰 발급 (userId, role 등 포함)
클라이언트는 토큰을 로컬스토리지나 세션스토리지에 저장
요청 시마다 Authorization: Bearer 헤더로 토큰 전송
서버는 토큰을 검증하고 사용자 정보 확인
사용자 수가 적거나,
빠르게 만료되는 인증이 필요한 경우
서버에 상태 저장이 가능할 때
모바일 앱 혹은 SPA(Single Page Application) 구조
분산 서버 환경 (서버 간 공유 불필요)
무상태 아키텍처(Stateless) 추구
세션은 서버 중심의 인증,
JWT는 클라이언트 중심의 인증이라고 정리할 수 있습니다.
각각의 장단점이 뚜렷하므로, 프로젝트의 성격과 구조에 따라 선택하는 것이 중요합니다.
은행 웹사이트처럼 일정 시간 동안 로그인 상태를 유지하다가 자동 로그아웃되는 방식은 세션 기반 인증이다.
서버가 로그인한 사용자의 세션 정보를 서버 메모리(RAM)에 저장하고 관리한다.
로그인 시 서버가 세션 ID를 생성하여 클라이언트의 쿠키에 저장.
서버는 세션 ID에 해당하는 사용자 정보를 메모리에 저장하여 계속 관리해야 함.
서버 자원을 계속 사용하게 되므로, 사용자 수가 많아지면 서버 부담이 커짐.
보안 측면에서는 상대적으로 더 안전함 (모든 정보가 서버에 있음).
로그인 시 사용자 정보를 담은 토큰(JWT)을 발급하고, 클라이언트에 저장(LocalStorage 등).
요청할 때마다 HTTP 헤더에 토큰을 담아 보냄.
서버는 토큰을 검증만 하므로 상태를 저장하지 않음 → Stateless
서버 리소스를 거의 쓰지 않음 → 확장성이 좋음.
빠른 응답 속도를 가짐 (서버의 조회 필요 없음).
✅ 핵심 요약 한 줄씩
🏦 은행처럼 자동 로그아웃되는 로그인 유지 방식 = 세션
🧠 세션은 서버 메모리를 사용해서 사용자를 기억함
📦 JWT는 클라이언트에 토큰을 저장해서 인증함
🔋 서버 자원이 부족하거나 확장성이 중요할 땐 JWT
🔐 보안은 세션 > JWT, ⚡ 속도는 JWT > 세션