세션과 쿠키 그리고 JWT

HTTP의 'Stateless'

HTTP는 기본적으로 'Stateless' 프로토콜이다. 즉, 서버는 요청의 상태를 기억하지 않는다. 따라서 서버는 클라이언트를 식별할 방법이 필요했고 이를 해결하기 위해 쿠키, 세션 그리고 JWT 가 등장

쿠키

웹 브라우저(클라이언트)에 저장되는 작은 데이터 조각

1. 서버가 필요한 데이터를 포함한 쿠키를 생성
2. 서버는 생성된 쿠키를 Set-Cookie 응답 헤더를 통해 클라이언트에 전송
3. 클라이언트는 전달받은 쿠키를 웹 브라우저의 저장소에 저장
4. 클라이언트는 서버에 요청을 보낼 때, 자동으로 Cookie 요청 헤더를 통해 해당 쿠키를 서버로 전달

로그인 구현 방식

1. 세션 기반 인증 방식
2. 토큰 기반 인증 방식

세션 기반 인증 방식

HTTP의 Stateless한 통신을 하면서 사용자와의 상태를 유지하기 위한 방법이다.

세션 : 서버와 클라이언트의 연결이 활성화된 상태를 의미
세션ID : 서버 또는 DB에 저장되는 클라이언트에 대한 유니크한 ID

작동 원리

1. 로그인 요청 시 서버에 세션ID를 생성하고 저장
2. 서버는 생성된 세션ID를 쿠키에 담아 클라이언트에 전달
3. 클라이언트가 요청을 보낼 때, 세션ID를 쿠키에 포함시켜 서버에 전달
4. 서버는 요청 쿠키에 있는 세션ID를 통해 저장소에 접근해 해당 세션 정보를 조회

단점

• 클라이언트 수가 많아지면, 세션 ID와 관련된 모든 정보를 서버가 저장해야 하므로 메모리 과부하가 발생할 수 있습니다.

토큰 기반 인증 시스템

상태(State)를 모두 토큰 자체에 저장해 서버는 모두 Stateless하게 유지

도입 배경

• 단일 서버 환경에서는 세션을 통해 클라이언트의 상태를 서버에 유지하는 것이 가능
• 다중 서버 환경(MSA)에서는 각 서버가 독립적으로 세션 정보를 유지해야 하므로, 세션 정보를 중앙화 하거나 동기화 작업이 필요 -> 관리가 어려워짐
• JWT는 서버 상태를 유지하지 않고도 클라이언트의 상태 관리가 가능하고 모든 서버가 클라이언트의 세션 정보를 공유할 필요 없이, 토큰만으로 상태 관리할 수 있다.

작동 원리

1. 인증 로직을 통해 JWT 토큰 생성
2. 사용자가 이후에 Access 토큰을 요청 헤더에 저장하고 인증이 필요한 서버에 요청

JWT 구조

1. Header
2. Payload
3. Signature

장점 : 별도의 인증저장소가 필요 없음 -> 메모리 저장
단정 : 토큰이 탈취당할 경우 데이터 유출이 가능