쿠키와 세션 + 캐시

쿠키와 웹 스토리지(로컬 스토리지, 세션 스토리지)의 차이점, 쿠키의 옵션, 쿠키와 세션의 차이점, 세션 기반 인증 방식과 토큰 기반 인증 방식의 차이점을 알아보겠습니다.

이 시리즈는 총 4개의 글에 나눠 작성합니다.
쿠키는 프론트엔드에서 매우 중요한 만큼 3개의 글에 등장합니다.

쿠키는 매우 중요한 만큼 3개의 글에 걸쳐 등장합니다.
Keyplus를 개발하면서도 JWT를 저장하는 데에 쿠키를 사용하였으나 제대로 알고 사용하지 않았습니다. 이번 기회에 제대로 알아보려 합니다.

  1. 로컬 스토리지, 세션 스토리지 그리고 쿠키 + IndexedDB
  2. 쿠키 파헤치기
  3. 쿠키와 세션 + 캐시 👈🏻
  4. 세션 기반 인증과 토큰 기반 인증

쿠키와 세션

쿠키와 세션은 둘 다 사용자가 특정 서버의 웹사이트에 방문했던 정보를 기억하고 해당 서버가 이를 재사용하기 위한 수단입니다.

HTTP 프로토콜의 Connectionless(클라이언트가 요청을 보내고 서버가 응답하면 그 즉시 해당 연결 종료), Stateless(연결이 끊어지면 그 전의 상태 정보는 유지되지 않고 소멸) 이 2가지 특성 때문에 서버가 사용자의 정보를 기억하기 위해 쿠키와 세션을 사용합니다.

세션은 사용자의 정보를 서버 쪽에 저장하는 방식(session_id는 클라이언트 쪽에 저장, 정보는 서버에 저장)이고, 쿠키는 사용자의 정보를 클라이언트 쪽에 저장하는 방식(혹은 정보 그 자체 또는 저장소)입니다.

쿠키

  • 서버가 웹 브라우저에 정보를 저장하고 불러올 수 있는 수단 (아무 때나 불러올 수 있는 건 아니고, Cookie 옵션 설정에 따름 -> 쿠키 파헤치기에서 자세히 다룸)
  • HTTP 요청을 보내는 서버의 도메인에 대해 쿠키가 존재하면, 웹 브라우저는 자동으로 쿠키를 함께 전달 (상황에 따라 Cookie 옵션 설정에 맞지 않으면 안 보내질 수도 있음 -> 쿠키 파헤치기에서 자세히 다룸)
  • 쿠키는 삭제하지 않으면(또는 만료 기한이 지나지 않으면) 사라지지 않음 -> 장기간 저장해야 하는 옵션을 클라이언트에 저장하기 적합함

쿠키는 클라이언트의 하드디스크(persistent-cookie) 혹은 브라우저의 메모리(session-cookie)에 저장하는 작은 정보 조각들을 의미합니다. 클라이언트마다 총 300개의 쿠키를 저장할 수 있고, 도메인당 20개를 저장할 수 있습니다. 하나의 쿠키는 최대 4KB의 데이터를 저장할 수 있습니다.

장점은 서버가 아닌 클라이언트에 데이터를 저장하기 때문에 서버의 부하를 줄일 수 있다는 것이고, 단점은 서버보다 보안이 취약한 클라이언트에 정보를 저장하기 때문에 보안 위협에 취약하다는 것입니다.

또, 방문했던 웹 사이트에 대한 정보 및 개인정보가 기록되기 때문에 사생활을 침해할 소지가 있습니다. 이를 해소하기 위해서 웹 브라우저 자체에 쿠키 거부 기능이 있습니다. 이러한 쿠키에 대한 거부가 웹 브라우저에 설정되어 있으면, 쿠키 본래의 목적인 웹 브라우저와의 연결을 지속시키는 기능을 수행할 수 없는 경우가 발생합니다.

동작 방식

  1. 클라이언트가 웹 사이트에 처음 요청을 전송한다.
  2. 서버에서 그 요청의 정보를 담은 쿠키를 생성한다(저장을 하지는 않는다).
  3. 해당 쿠키를 응답의 Set-Cookie 헤더에 담아 클라이언트에게 전송한다.
  4. 클라이언트는 전송받은 쿠키를 하드디스크 혹은 브라우저의 메모리에 저장한다.
  5. 이후 클라이언트가 동일한 웹 사이트에 다시 요청을 하면, 저장하고 있던 쿠키를 요청의 Cookie 헤더에 담아 서버에게 전송한다.
  6. 서버는 전송받은 쿠키를 통해 이전 상태 정보를 확인하고, 이에 맞게 클라이언트에게 적절한 방식으로 응답한다. 만약 업데이트해야 할 상태 정보가 있다면 변경된 쿠키를 응답의 Set-Cookie 헤더에 담아 클라이언트에게 전송한다.

사용 예시

  • 오늘 더 이상 이 창을 보지 않음 체크
  • 비회원 장바구니
  • 테마 (e.g. Light/Dark)

세션

세션은 데이터를 서버에 저장하고, 클라이언트(쿠키)에는 데이터에 대한 유일하고 암호화된 ID만 부여합니다.

장점은 클라이언트보다 보안이 강한 서버에 저장이 되기 때문에 보안 위협에 덜 취약하다는 것이고, 단점은 사용자가 많아지면 서버의 부하가 심해질 수도 있다는 것입니다.

동작 방식

  1. 클라이언트가 웹 사이트에 요청을 전송한다.
  2. 서버는 요청의 Cookie 헤더에 세션 ID가 없음을 확인하고 (세션 생성이 필요한 경우라면) 새로운 세션을 생성한 뒤 해당 세션 ID(유일하고 암호화됨)를 발급한다.
  3. 해당 세션 ID를 응답의 Set-Cookie 헤더에 담아 클라이언트에게 전송한다.
  4. 클라이언트는 전송받은 세션 ID를 쿠키로 저장한다.
  5. 이후 클라이언트가 동일한 웹 사이트에 다시 요청을 하면 요청의 Cookie 헤더에 세션 ID를 담아 서버에게 전송함으로써 하나의 세션이 유지되고, 서버가 클라이언트를 식별할 수 있게 한다.

사용 예시

로그인 유지 (세션 기반 인증과 토큰 기반 인증에서 자세하게 다룹니다.)

세션 기반 인증

세션은 쿠키의 보안이 취약하다는 점을 보완하기 위해 사용하나 쿠키를 기반으로 동작하기 때문에 XSS 공격으로 쿠키가 탈취된다면 여전히 개인 정보 유출의 위험이 있습니다. (쿠키는 세션 아이디, 즉 인증 성공에 대한 증명을 갖고 있으므로 탈취될 경우 서버는 해당 요청이 인증된 사용자의 요청이라고 판단합니다. 이것이 우리가 공공 PC에서 로그아웃해야 하는 이유입니다.)

로그아웃 시 해야 하는 작업

  1. 서버의 세션 정보 삭제
  2. 클라이언트의 쿠키 삭제

일단은 여기까지만 알아보고, 인증에 관한 부분은 세션 기반 인증과 토큰 기반 인증에서 자세히 다루도록 하겠습니다.

쿠키와 세션의 차이점

저장 위치

쿠키는 클라이언트(브라우저) 메모리 또는 하드디스크에 파일로 저장하고, 세션은 서버에(in-memory(자바스크립트 객체 등) 또는 세션 스토어(redis 등과 같은 트랜잭션이 빠른 DB))에 저장합니다.

보안

쿠키는 클라이언트에 저장되는데 특히 파일로 저장되는 경우(persistent-cookie) 탈취, 변조될 위험이 있고, 요청/응답에서 탈취당할 위험이 있어 보안이 취약합니다. 따라서 쿠키에는 민감하거나 중요한 정보를 담는 것은 위험합니다.

반면, 세션은 정보 자체는 서버에 저장되어 있으므로 비교적 안전합니다.

라이프 사이클

쿠키는 persistent-cookie의 경우 브라우저를 종료하더라도 유지된다. 반면, 세션은 서버에서 만료시간/날짜를 정해서 지워버릴 수 있기도 하고, session-cookie에 세션 ID를 저장한 경우 브라우저 종료 시 삭제된다.

속도

쿠키는 요청 시 헤더를 바로 참조하면 되므로 세션보다 속도에서 유리하다. 반면, 세션은 제공받은 session-id(key)를 이용해서 서버에서 다시 데이터를 참조해야 하므로 속도가 비교적 느릴 수 있다.

캐시란?

추가 예정

참고


Written by정선아
🌱 공부한 것을 기록하여 성장하기 위한 블로그입니다.

GitHubGmail