🖥 쿠키(Cookie)와 세션(Session)

💬 Cookie 와 session의 등장

HTTP 는 비연결 지향으로 서버가 클라이언트의 요청에 따라 응답을 보내주면 바로 연결을 끊는다.(Connectionless) 또한, 연결을 끊는 순간 클라이언트와 서버의 통신이 종료되며 상태 정보를 유지하지 않는다.(Stateless) 이와 같은 특성으로 HTTP 프로토콜은 모든 요청 간의 의존 관계가 없어 현재 접속한 사용자가 이전에 접속한 사용자와 같은 사용자인지 알 수 없다. 

 

즉, 클라이언트와 서버가 통신할 때마다 새롭게 연결해야 하며 클라이언트는 매 요청마다 인증 과정을 거쳐야 한다. 따라서, HTTP 프로토콜에서 이전 요청과 현재 요청이 같은 사용자의 요청인지 알게 되는 상태 유지를 위해 쿠키와 세션을 사용하게 되었다.

 

 

💬 Cookie

Stataless한 상태의 프로토콜에서 상태기반 정보를 기억할 수 있는 쿠키가 개발되고 서버는 쿠키를 이용해서 사용자를 인증 할 수 있게 되었다.

 

쿠키란 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각이다. 브라우저는 작은 데이터 조각을 저장해 두었다가 동일한 서버에 재요청시 저장된 데이터를 함께 전송한다.

 

주로 3가지의 목적으로 사용된다.

1. 세션관리 : 서버에 저장해야할 로그인, 장바구니, 게임 스코어 등의 정보를 관리
2. 개인화 : 사용자 선호, 테마 등의 셋팅
3. 트래킹 : 사용자 행동을 기록하고 분석하는 용도

 

set-cookie 그리고 cookie 헤더

HTTP요청을 수신할 때, 서버는 응답과 함께 Set-Cookie 헤더를 전송할 수 있다.

TTP/1.0 200 OK
Content-type : text/html
Set-Cookie : someone_cookie=lalalala
Set-Cookie : late_cookie=work

이런식으로 서버가 클라이언트에게 전달하는 데이터의 헤더에 설정하면 set-cookie에 해당하는 값을 저장하라고 명령하는 것이다.

 

그렇다면 이제 브라우저는 서버로 전송하는 요청이 이렇게 될 것이다.

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie:someone_cookie=lalalala;late_cookie=work

이렇게 서버에서 전송해준 모든 쿠키를 실어서 전송하게 되는 것이다.

 

쿠키 속성

크롬개발자에서 "애플리케이션 → 쿠키" 를 클릭해보면 쿠키가 Name = Value 쌍으로 이루어져있는 것을 확인해볼수 있다. 그리고 다양한 속성들 또한 볼 수 있는데 하나씩 알아보자

 

• Domain 과 Path
  • Domain 그리고 Path는 어떤 URL을 쿠키가 보내야하는지 정의한다.
  • Domain은 쿠키가 전송되게 될 호스트들을 명시하게 된다. 만약 명시되지 않는다면, 현재 문서 위치의 호스트를 기본값으로 한다.
  • Path는 Cookie 헤더를 전송하기 위해서 요청되는 URL 내에 반드시 존재해야 하는 URL 경로이다.
• Secure와 HttpOnly
  • Secure는 HTTPS 프로토콜상에서 암호화된 요청일 경우에만 전송된다.
  • HttpOnly는 XSS 공격을 방지하기 위해 JavaScript의 Document.cookie API에 접근할 수 없다.
    • 예를 들어 서버쪽에서 지속되고 있는 세션의 쿠키는 JavaScript를 사용할 필요성이 없기 때문에 HttpOnly 플래그가 설정될 것이다.
  • SameSite를 선언했을 경우 쿠키가 cross-site 요청시에 전송하지 않아서 CSRF에 대해 방어할 수 있다.

 

쿠키 종류

쿠키 이름	특징
Session Cookie	메모리에만 저장되며 브라우저 종료시 쿠키를 삭제한다.
Persistent Cookie	장기간 유지되는 쿠키(Max-Age 1년 정도), 파일로 저장되어 브라우저 종료와 관계없이 사용
Secure Cookie	HTTPS에서만 사용된다. 쿠키 정보가 암호화 되어 전송된다
Third-Party Cookie	방문한 도메인과 다른 도메인의 쿠키, 보통 광고 베너 등을 관리 할 때 유입 경로를 추적하기 위해 사용

※ Set-Cookie를 할 때 Expires 속성이 존재하지 않으면 Session Cookie로 간주하며 Expires 속성이 존재한다면 기간 동안은 브라우저를 닫아도 사라지지 않는 persistent cookie로 간주한다.

 

쿠키 단점

• 보안에 취약하다 : 요청시 쿠키의 값을 그대로 전송한다
• 용량이 작다
• 웹 브라우저마다 지원 형태가 다르다. 
• 한번에 하나의 정보만 저장 할 수 있다.
• 문자열 그대로 통신하여 위변조가 가능하다.

 

 

💬 Session

세션이란 일정 시간 동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고 그 상태를 일정하게 유지시키는 기술이다. 세션은 중요한 정보를 클라이언트에 저장하는 쿠키와는 다르게 서버에 저장하고 관리하기 때문에 사용자의 정보가 노출되지 않는다. 서버에서는 클라이언트를 구별하기 위해 각각의 세션 ID를 클라이언트마다 부여하게 되며 클라이언트가 종료되기 전까지 유지한다.

 

서버(세션) 기반 인증

이전에 쿠키만을 사용해서 인증을 했을 경우에는 클라이언트에서 사용자 정보를 관리하여 보안에 매우 취약하다는 단점이 존재하여 요즘에는 로그인과 같이 보안상 중요한 작업을 진행할 때는 세션을 사용한다.

 

예를 들어 사용자가 로그인을 하면, 세션에 사용자 정보를 저장해두고 서비스를 제공할 때 사용하곤 한다. 

 

 

진행 과정

1. 사용자가 아이디와 비밀번호를 이용해서 로그인을 진행한다
2. 서버 측에서 해당 정보를 검증한다
3. 정보가 정확하다면 서버측에서 Set-Cookie를 통해 새로 발행한 SessionId를 보낸다.
4. 클라이언트 요청시마다 서버에 저장된 세션 ID와 클라이언트에 있는 SessionID가 일치한지 확인하여 작업한다.

하지만 서버 기반 인증 방식은 서버를 확장하기 어렵다는 단점이 명확하게 존재했다.

 

서버 기반 인증의 단점(문제)

• 서버의 부하
  • 서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로, 클라이언트 수에 따른 메모리나 디스크 또는 DB에 부하가 심하다.
• 확장성
  • 사용자가 급증하게 되면 더 많은 트래픽을 처리하기 위해 서버를 확장해야 하는데 서버를 확장 할 때 세션이 저장되어있는 서버로만 요청이 가도록 분산처리를 해주어야 하기 때문에 서버의 확장이 쉽지 않다
• CORS
  • 웹 브라우저에서 세션 관리에 사용하는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 CORS 방식(여러 도메인에 request를 보내는 브라우저)을 사용할 때 쿠키 및 세션 관리가 어렵다.

 

토큰 기반 인증

서버 기반 인증의 단점을 보완하기 위해 등장한 토큰 기반인증 방식은 인증받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 대 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 한다. 이러한 시스템에서는 더이상 사용자의 인증 정보를 서버나 세션에 유지하지 않고 클라이언트 측에서 들어오는 요청만으로 작업을 처리한다.

 

즉, 서버 기반의 인증 시스템과 달리 상태를 유지하지 않기때문에 Stateless한 구조를 갖게 된다.

 

 

진행과정

1. 사용자가 아이디와 비밀번호로 로그인을 진행한다.
2. 서버 측에서는 해당 정보를 검증한다.
3. 정보가 정확하다면 서버측에서 사용자에게 토큰을 발급한다.
4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 서버에 함께 전달한다.
5. 서버는 토큰을 검증하고, 요청에 응답한다.

 

토큰 기반 인증 시스템의 장점

1. 무상태성 & 확장성
   • 토큰은 클라이언트 측에 저장되기 때문에 서버는 완전히 Stateless 하며, 클라이언트와 서버의 연결고리가 업식 때문에 확장하기에 매우 적합하다
2. 여러 플랫폼 및 도메인
   • 서버 기반 인증 시스템의 문제점 중 하나인 CORS를 해결할 수 있다. 토큰을 사용한다면 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리 할 수 있다
   • 최근 가장 많이 사용되는 것은 JSON 포맷을 이용한 JWT이다.