세션 기반 인증 vs 토큰(쿠키) 기반 인증 은 개발자 면접에서 자주 나오는 질문 중의 하나!

1. 동작순서

stateful 한 방식

2. 세션 저장소

• 기본적으로 세션 저장소를 필요로 하므로, Redis 를 多 사용
  (Redis: Key, Value 구조의 비정형 데이터를 저장하고 관리하기 위한 오픈 소스 기반의 비관계형 DBMS(데이터 베이스 관리 시스템))

• 로그인을 했을 때, 사용자의 정보를 저장하고 열쇠가 되는 세션ID값을 만든다. 그리고 이를 HTTP 헤더에 실어 사용자에게 돌려보낸다.

• 사용자는 세션ID를 쿠키로 보관하고 있다가, 인증이 필요한 요청에 쿠키(세션ID)를 넣어보낸다.

• 웹 서버에서는 세션 저장소에서 쿠키(세션ID)를 받고, 저장되어 있는 정보와 매칭시켜 인증을 완료한다.

3. 쿠키, 세션

쿠키 vs 세션 은 개발자 면접에서 자주 나오는 질문 중의 하나!

참고: 쿠키(Cookie), 세션(Session)

4. 장단점

장점

1. 세션 저장소에 저장된 유저의 정보를 얻기위해 쿠키를 매개로 인증을 거치므로
   도중에 쿠키가 담긴 Http 요청이 노출되더라도, 쿠키 자체는 유의미한 값을 가지지 X
   → 보안상 이점

2. 각 사용자들은 고유한 ID값을 발급받으므로,
   서버는 쿠키값을 박고, 일일이 회원정보를 확인하지 않아도 각 회원을 구별 가능
   → 그래서, 서버 접근이 용이

단점

1. 해커가 사용자 A 의 Http 요청을 가로챌 경우 그 안의 쿠키도 훔칠 수 있음
   → 그래서, 해커는 훔친 쿠키로 Http 요청을 보내고, 세션 저장소는 사용자 A 의 요청으로 오인하여 정보를 제공해주게 됨
   (= 세션 하이재킹 공격)
   → 해결책 : 세션에 유효시간을 넣기

2. 서버가 세션 저장소를 사용하면, 서버에 추가적인 저장공간이 필요
   → 그만큼 부하↑ (서버 부담)

3. scale-out 으로 서버의 성능을 늘릴 경우,
   서버의 세션을 동기화하는 추가적인 비용 발생 가능성

4. 사용자의 데이터를 서버의 메모리에 저장하므로, 메모리 용량에 대한 리스크

5. 확장성 한계

   • 일반적으로 웹 어플리케이션의 서버 확장 방식은 수평 확장(한 대가 아닌 여러 대의 서버가 요청을 처리함)을 사용하는데,
     이때 별도의 작업을 해주지 않는다면, 세션 기반 인증 방식은 세션 불일치 문제를 겪게 된다.
     이를 해결하기 위해서 Sticky Session, Session Clustering, 세션 스토리지 외부 분리 등의 작업을 해주어야한다.

scale-out, scale-up

• scale-out : 서버의 갯수를 늘려서 성능을 올리는 방법
• scale-up : 서버 자체의 성능(디스크의 용량 등)을 올리는 방법

Session / Cookie 방식은 서버의 메모리에 의존적이기 때문에
scale-out 으로 성능을 올릴 경우, 세션에 대한 데이터를 어떻게 공유시킬 건지에 대한 고민도 필요

참고: Scalability 와 Elasticity

---

참고: stateful과 stateless, 인증방식
참고: [서버 공통] 세션 / 쿠키 / 토큰의 차이점
참고: 세션 기반 인증과 토큰 기반 인증 (feat. 인증과 인가)