쿠키와 세션 (Cookie & Session)

1. HTTP의 인증, 쿠키, 세션

• HTTP는 무상태(stateless) 프로토콜이기 때문에, 클라이언트와 서버 간의 연결 상태를 유지하지 않는다.
• 따라서 사용자의 로그인 상태를 유지하거나, 요청을 인증하는 기능이 필요하다.
• 이를 위해 HTTP는 인증(Authentication), 쿠키(Cookie), 세션(Session) 등의 기술을 사용한다.

 

1.1 HTTP 인증 (Authentication)

• HTTP 요청을 보낸 클라이언트가 "누구인지" 확인하는 과정

 

1.1.1 HTTP 기본 인증 방식

• Basic Autentication: 가장 단순한 방식으로, 아이디와 비밀번호를 Base64로 인코딩하여 전달
• Digest Authentication: Basic 방식보다 보안이 강화된 방식 (해시 기반 인증)
• Token-Based Authentication: JWT, OAuth 등 토큰을 이용한 인증
• OAuth 2.0: 제3자 인증 방식 (SNS 로그인 등)

1.1.1.1 Basic Authentication (기본 인증)

• 클라이언트는 Authorization 헤더에 아이디:비밀번호를 Base64로 인코딩하여 서버에 전달
• 보안이 취약하기 때문에 HTTPS 환경에서만 사용해야 함.

요청 예제

GET /secure-data HTTP/1.1
Host: example.com
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=  = Base64(username:password)

 

응답 예제 (인증 필요)

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="Restricted Area"

 

 

1.1.1.2 Token-Based Authentication (토큰 인증)

• 로그인 후 서버가 토큰을 발급하고, 이후 요청 시 토큰을 인증하는 방식

동작 과정

1. 클라이언트가 로그인 (POST /login)
2. 서버가 토큰(JWT, OAuth 토큰 등) 발급 후 클라이언트에게 전달
3. 이후 클라이언트는 요청마다 Authorization 헤더에 토큰을 포함하여 전송
4. 서버는 토큰을 검증 후 응답

요청 예제

GET /user/profile HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

 

장점

• 세션을 서버에서 관리할 필요가 없음. (서버 부담 감소)
• 확장성이 뛰어남 (OAuth, JWT 활용 가능)

단점

• 토큰 탈취 시 보안 문제 발생 가능 (토큰 유효 기간을 설정해야 함.)

 

1.2 쿠키 (Cookie)

• 클라이언트(브라우저)에 저장되는 작은 데이터
• 주로 로그인 상태 유지, 사용자 식별, 트래킹 등에 사용됨.
• 서버가 클라이언트에게 쿠키를 세팅 요청(Set-Cookie:)하면 (스티커를 붙이면)
• 클라이언트는 이후 서버에게 보내는 요청 헤더에 쿠키(Cookie:)를 표시해서 전송 (스티커를 붙인 채 돌아와야 함.)

 

1.2.1 쿠키의 구조

• 쿠키는 Set-Cookie 헤더를 사용하여 서버에서 클라이언트에게 전달된다.

서버 응답 예제

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure

 

• session_id=abc123 -> 쿠키 값
• Path=/ -> 쿠키가 적용될 경로
• HttpOnly -> JavaScript에서 접근 불가 (보안 강화)
• Secure -> HTTPS에서만 전송됨

 

클라이언트 요청 예제

GET /dashboard HTTP/1.1
Cookie: session_id=abc123

브라우저는 자동으로 Cookie 헤더를 포함하여 서버로 요청

 

1.2.2 쿠키 속성

• Expires: 쿠키 만료 날짜 (Set-Cookie: session_id=abc123; Expires=Wed, 21 Oct 2025 07:28:00 GMT)
• Max-Age: 쿠키 유지 시간(초 단위)
• Domain: 쿠키가 유효한 도메인 (예: Domain=example.com)
• Path: 쿠키가 적용되는 URL 경로 (Path=/admin이면 /admin/*에서만 적용
• HttpOnly: JavaScript에서 접근 불가능 (XSS 공격 방지)
• Secure: HTTPS 환경에서만 쿠키 전송 가능
• SameSite: 크로스 사이트 요청 제한 (Strict, Lax, None)

 

1.2.3 쿠키의 장점과 단점

장점

• 간편한 사용자 상태 유지 가능 (로그인 유지)
• 클라이언트에서 저장되므로 서버 부담 감소

단점

• 보안 취약점 (쿠키 탈취 시 세션 도용 가능 -> HttpOnly, Secure 설정 필요) 로그인 관련 정보를 쿠키에만 넣어둔다면?
• 클라이언트 저장 공간 제한 (4KB 제한)
• 크로스사이트 공격 (CSRF) 위험

 

1.2.4 쿠키의 종류

• 쿠키는 HTTP 통신에서 사용자 상태를 유지하는 데 사용되는 작은 데이터 조각이다.
• 쿠키는 사용 목적, 보안 설정, 유지 기간 등에 따라 여러 가지로 분류할 수 있다.

1.2.4.1 저장 기간에 따른 분류

• 세션 쿠키: 브라우저가 종료되면 자동 삭제됨.
• 영구 쿠키: 특정 만료 시간까지 유지됨.

 

1.2.4.2 쿠키를 보안 설정에 따른 분류

• 보안 쿠키: HTTPS에서만 전송 가능
• HttpOnly 쿠키: JavaScript에서 접근 불가능
• SameSite 쿠키: CSRF 공격 방지 (Strict, Lax, None)

 

1.2.4.3 도메인과 경로 설정에 따른 분류

• 도메인 쿠키: 특정 도메인에서만 사용 가능
• 경로 쿠키: 특정 경로에서만 사용 가능

 

1.2.4.4 생성 주체에 따른 분류

• 퍼스트 파티 쿠키: 사용자가 방문한 웹사이트에서 생성
• 서드 파티 쿠키: 광고, 분석 서비스 등 외부 도메인에서 생성

 

1.3 세션 (Session)

• 서버에서 클라이언트의 상태를 유지하는 방법
• 쿠키와 함께 사용하여 로그인 상태를 관리하는 것이 일반적

1.3.1 세션 동작 방식

1. 클라이언트가 로그인 요청 (POST /login)
2. 서버에서 고유한 세션 ID를 생성 후 저장
3. 서버는 Set-Cookie 헤더를 통해 세션 ID를 클라이언트에 전달
4. 이후 클라이언트는 요청 시 세션 ID를 포함하여 서버로 요청
5. 서버는 세션 ID를 확인하고, 해당 사용자 정보를 반환

 

1.3.2 세션 예제

1.3.2.1 클라이언트 로그인 요청

POST /login HTTP/1.1
Host: example.com
Content-Type: application/json

{
    "username": "johndoe",
    "password": "secure123"
}

 

1.3.2.2 서버 응답 (세션 생성 후 쿠키 설정)

HTTP/1.1 200 OK
Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure

 

1.3.2.3 이후 요청에서 세션 사용

GET /dashboard HTTP/1.1
Cookie: session_id=abc123

• 서버는 session_id 값을 조회하여 로그인한 사용자 정보 반환

 

세션과 쿠키의 차이점