세션(Session)과 쿠키(Cookie) 비교, 토큰(Token)과의 관계
세션(Session)과 쿠키(Cookie)는 모두 웹 애플리케이션에서 클라이언트와 서버 간 상태를 유지하기 위해 사용됩니다. 이 둘은 목적은 비슷하지만 작동 방식, 저장 위치, 보안 측면 등에서 차이가 있습니다.
1. 세션(Session)과 쿠키(Cookie)의 주요 차이
항목
세션(Session)
쿠키(Cookie)
저장 위치
서버 측(Session Storage)
클라이언트 측(브라우저)
데이터 저장
사용자 데이터를 서버에 저장, 클라이언트는 세션 ID만 저장
모든 데이터를 클라이언트에 저장 (키-값 형태)
수명
브라우저 종료 시 기본적으로 만료, 또는 서버에서 설정한 시간까지 유지
만료 시간을 설정할 수 있으며, 기본적으로 브라우저 종료 시 만료
보안
상대적으로 안전 (민감한 데이터가 서버에 저장)
데이터가 클라이언트에 저장되므로 보안에 취약할 수 있음
크기 제한
서버 메모리 또는 저장소 크기에 따라 다름
4KB로 제한
통신 방식
세션 ID를 쿠키 또는 URL 파라미터를 통해 전달
HTTP 요청 시 자동으로 서버에 전송
작동 방식
클라이언트 요청 시 세션 ID로 서버의 데이터를 조회
클라이언트가 요청 시 데이터를 직접 서버에 전송
성능
서버 리소스를 소모
클라이언트 리소스 사용
사용 사례
사용자 인증, 민감한 데이터 처리
사용자 설정 저장(예: 테마, 언어 설정), 간단한 상태 정보 저장
2. 세션(Session)과 쿠키(Cookie)의 관계
쿠키는 세션과 함께 사용되는 경우가 많습니다.
세션 ID(Session ID)를 쿠키에 저장하여 클라이언트와 서버 간 상태를 유지합니다.
서버는 클라이언트로부터 세션 ID를 받아 세션 데이터를 조회합니다.
이 방식은 쿠키를 통해 클라이언트와 서버 간 세션 상태를 연결합니다.
3. 토큰(Token)과 세션/쿠키의 상관관계
토큰(Token)은 세션/쿠키와 비슷한 목적(상태 유지 및 인증)을 가지지만, Stateless(무상태) 방식으로 설계되었습니다. 아래에서 토큰과 세션/쿠키의 관계를 설명합니다.
3.1. 토큰(Token)이란?
토큰은 사용자를 인증하고 상태를 유지하기 위해 클라이언트와 서버 간에 교환되는 데이터 구조입니다.
JWT (JSON Web Token)는 가장 널리 사용되는 토큰 형식.
자체적으로 사용자 정보와 인증 데이터를 포함(자급자족형 데이터).
3.2. 세션 기반 인증과 토큰 기반 인증의 차이
항목
세션 기반 인증
토큰 기반 인증
상태(State)
Stateful (서버가 상태를 유지)
Stateless (서버가 상태를 유지하지 않음)
저장 위치
서버에서 세션 데이터를 저장
클라이언트에서 토큰을 저장 (쿠키, 로컬 스토리지 등)
확장성
서버 메모리를 소비하므로 확장성에 한계가 있음
서버는 상태를 유지하지 않으므로 확장성이 뛰어남
보안
세션 ID가 탈취되면 인증 상태를 가로챌 수 있음
토큰이 탈취되면 인증 상태를 가로챌 수 있음
전송 방식
쿠키를 통해 세션 ID 전송
HTTP 헤더(Authorization: Bearer Token)를 통해 전송
사용 사례
전통적인 웹 애플리케이션
RESTful API, SPA(Single Page Application)
3.3. 세션/쿠키와 토큰의 공통점
상태 유지: 둘 다 클라이언트-서버 간 인증 상태를 유지하는 목적.
전송 방식:
세션: 쿠키를 통해 세션 ID를 전송.
토큰: HTTP 헤더(Authorization)나 쿠키를 통해 토큰을 전송.
보안:
모두 탈취당하면 동일한 보안 문제가 발생.
HTTPS와 같은 추가적인 보안 계층을 사용해야 함.
3.4. 세션/쿠키와 토큰의 주요 차이
서버 부담:
세션은 서버가 클라이언트의 상태를 저장하므로, 동시 접속자가 많아지면 서버 부담이 증가.
토큰은 서버가 상태를 저장하지 않으므로 확장성에 유리.
확장성:
세션 기반 인증은 분산 환경에서 세션 동기화가 필요(예: Redis, 데이터베이스).
토큰 기반 인증은 클라이언트가 상태를 저장하므로 별도의 동기화가 필요 없음.
보안:
세션 ID는 서버에서 관리되고, 토큰은 클라이언트에서 관리됨.
토큰은 자체적으로 정보(페이로드)를 포함하므로 탈취 시 민감한 정보가 노출될 가능성이 높음.
4. 토큰 기반 인증의 동작 원리
4.1. JWT 구성
JWT는 세 부분으로 구성됩니다:
Header:
토큰 유형(JWT)과 해싱 알고리즘(예: HS256).
Payload:
사용자 정보와 클레임(Claim)을 포함.
예:
{"sub": "user1", "role": "admin"}.
Signature:
Header와 Payload를 암호화한 서명.
4.2. JWT 인증 흐름
사용자가 로그인하면 서버가 JWT를 생성하고 클라이언트로 전달.
클라이언트는 토큰을 저장(예: 쿠키, 로컬 스토리지).
이후 요청마다 토큰을 HTTP 헤더에 포함하여 전송:
서버는 토큰의 유효성을 검증하고, 사용자를 인증.
5. 세션, 쿠키, 토큰의 결합 사용
5.1. 토큰 + 쿠키
토큰을 쿠키에 저장하여 클라이언트-서버 간 상태를 유지.
쿠키의
HttpOnly속성을 활성화하여 JavaScript에서 접근하지 못하도록 보안 강화.
5.2. 세션 + 토큰
세션을 통해 클라이언트 상태를 관리하고, 추가적인 인증 정보를 토큰으로 제공.
예: 세션으로 사용자 인증, 토큰으로 API 호출 인증.
6. 선택 기준
요구사항
추천 방식
서버 확장성이 중요
토큰 기반 인증 (Stateless)
높은 보안성이 필요
세션 기반 인증 (Stateful)
단순한 인증 상태 유지
쿠키 기반 인증
SPA 또는 모바일 앱
토큰 기반 인증 (JWT)
전통적인 웹 애플리케이션
세션 기반 인증
결론
세션과 쿠키는 전통적인 상태 관리 방식으로 여전히 많이 사용되며, 보안 및 확장성을 위해 세션 ID와 쿠키를 결합하는 경우가 많습니다.
토큰 기반 인증은 Stateless한 인증 방식으로, 특히 RESTful API나 분산 시스템에서 더 적합합니다.
선택은 애플리케이션의 요구사항(보안, 확장성, 클라이언트 종류 등)에 따라 달라져야 하며, 실무에서는 세션, 쿠키, 토큰을 조합해 사용하는 경우도 많습니다.
Last updated