Cookie, Session, Token 기반 인증 완벽 가이드

HTTP의 무상태(stateless) 특성을 극복하기 위해 사용되는 Cookie, Session, Token 기반 인증 방식의 개념과 특징, 그리고 클라이언트 측 저장소에 관한 종합적인 설명이다.



인증의 필요성과 HTTP의 한계

HTTP 프로토콜은 기본적으로 무상태(stateless) 프로토콜이다. 각 요청은 독립적으로 처리되며, 서버는 이전 요청에 대한 정보를 기억하지 않는다. 이러한 특성 때문에 사용자 인증 상태를 유지하기 위한 추가적인 메커니즘이 필요하게 되었다.

HTTP 요청 예시:
GET /resource HTTP/1.1
Host: example.com

이 요청만으로는 서버가 요청자가 누구인지, 인증된 사용자인지 알 수 없다. 따라서 인증 정보를 전달하고 유지하기 위한 여러 방법이 개발되었다.

인증은 사용자가 자신이 주장하는 사람임을 확인하는 과정이며, HTTP의 무상태성을 극복하기 위해 쿠키, 세션, 토큰과 같은 다양한 인증 메커니즘이 사용된다.



쿠키(Cookie) 기반 인증

쿠키는 클라이언트의 웹 브라우저에 저장되는 작은 데이터 파일로, 클라이언트와 서버 간의 상태 정보를 유지하는 데 사용된다.



쿠키의 특징

  • 저장 위치: 클라이언트의 웹 브라우저에 저장
  • 전송 방식: HTTP 요청 헤더에 자동으로 포함되어 전송
  • 용량 제한: 일반적으로 4KB 이하의 작은 용량
  • 접근 제한: HttpOnly 플래그를 설정하여 JavaScript에서의 접근 제한 가능
  • 도메인 범위: 설정된 도메인 및 하위 도메인에서 사용 가능
쿠키 설정 예시(서버 응답):
HTTP/1.1 200 OK
Set-Cookie: user_id=123; Path=/; HttpOnly; Secure

💡 쿠키는 정보 전달의 매개체로서 항상 HTTP 헤더에 담겨 서버로 전송된다.



쿠키의 장단점

장점:

  • 서브도메인 간 동일한 세션 사용 가능
  • HttpOnly 플래그로 XSS 공격에 대한 보안 강화
  • 브라우저가 자동으로 관리하므로 구현이 간단
  • 저장 공간이 작아 네트워크 부하 최소화

단점:

  • 클라이언트 측에서 조작 가능성 존재
  • 모든 HTTP 요청에 포함되어 불필요한 데이터 전송 발생
  • 크로스 사이트 요청 위조(CSRF) 공격에 취약할 수 있음

쿠키는 브라우저에 저장되는 작은 텍스트 조각으로, HTTP 요청마다 자동으로 서버에 전송되어 사용자 상태를 유지하는 데 도움을 준다.



세션(Session) 기반 인증

세션은 서버 측에 상태 정보를 저장하는 기술로, 클라이언트는 세션 ID만 가지고 있고 실제 데이터는 서버에 저장된다.



세션의 동작 방식

  1. 사용자가 로그인하면 서버는 고유한 세션 ID를 생성
  2. 세션 ID와 사용자 정보를 서버의 세션 저장소에 저장
  3. 세션 ID를 클라이언트에게 쿠키로 전달
  4. 클라이언트는 이후 요청에 세션 ID가 담긴 쿠키를 포함하여 전송
  5. 서버는 세션 ID를 통해 사용자 정보를 조회하고 인증 상태 확인
세션 기반 인증 흐름:
1. 클라이언트: 로그인 요청(사용자명/비밀번호)
2. 서버: 인증 성공 → 세션 ID 생성 → 세션 저장소에 저장
3. 서버: 세션 ID를 쿠키로 클라이언트에 전송
4. 클라이언트: 이후 요청에 세션 ID를 쿠키 포함
5. 서버: 세션 ID로 세션 저장소 조회 → 인증 확인

⚡ 세션은 상태 유지(stateful) 방식으로, 서버가 클라이언트의 상태 정보를 기억한다.



세션의 장단점

장점:

  • 민감한 정보가 서버에만 저장되어 보안성 향상
  • 세션 데이터 관리와 무효화가 서버에서 용이
  • 클라이언트 측에서는 세션 ID만 관리하므로 단순

단점:

  • 서버 측 리소스 사용(메모리, 디스크 등)
  • 다중 서버 환경에서 세션 공유 문제 발생
  • 확장성(scalability) 제한
  • 세션 지원 장비에 의존적(제우스 등)

세션은 사용자와 서버의 관계가 기억되어 보존되는 상태를 의미하며, 서버 측에 데이터를 저장하고 클라이언트는 세션 ID만 보유하는 방식이다.



토큰(Token) 기반 인증

토큰 기반 인증은 서버가 클라이언트에게 암호화된 토큰을 발급하고, 클라이언트는 이 토큰을 사용하여 인증하는 방식이다.



JWT(JSON Web Token)

JWT는 가장 널리 사용되는 토큰 형식으로, 정보를 안전하게 전송하기 위한 컴팩트하고 자체 포함된(self-contained) 방식이다.

  • 구조: Header.Payload.Signature의 세 부분으로 구성
  • 특징: 서명된 토큰으로 정보의 무결성 보장
  • 저장소: Local Storage, Session Storage, 또는 쿠키에 저장 가능
JWT 구조 예시:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c



토큰 기반 인증 흐름

  1. 사용자가 로그인하면 서버는 사용자 정보를 확인
  2. 인증 성공 시 서버는 JWT를 생성하여 클라이언트에게 반환
  3. 클라이언트는 JWT를 저장(Local Storage, Session Storage, 쿠키 등)
  4. 이후 요청 시 클라이언트는 Authorization 헤더에 JWT를 포함하여 전송
  5. 서버는 JWT의 서명을 검증하고 요청을 처리
토큰 기반 인증 요청 예시:
GET /resource HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...



토큰 기반 인증의 장단점

장점:

  • 서버가 상태를 유지하지 않음(stateless) → 확장성 향상
  • 다양한 클라이언트 플랫폼(웹, 모바일 등) 지원
  • 마이크로서비스 아키텍처에 적합
  • 교차 도메인 요청(CORS) 처리 용이

단점:

  • 토큰 크기가 쿠키보다 클 수 있음
  • 토큰 무효화가 어려움(별도 블랙리스트 관리 필요)
  • 구현 복잡성 증가
  • 에러 발생 시 개발자의 책임 소재

토큰 기반 인증은 서버가 상태를 저장하지 않고도 사용자의 인증 상태를 확인할 수 있는 방식으로, JWT가 대표적인 구현 방식이다.



추가) 클라이언트 측 저장소

웹 애플리케이션에서 데이터를 저장하는 방법으로 쿠키 외에도 Web Storage API를 통한 저장 방식이 있다.



Session Storage

  • 특징: 브라우저 세션 동안만 데이터 유지
  • 범위: 탭/창 단위로 독립적으로 동작
  • 용량: 일반적으로 5MB 정도
  • 접근: JavaScript를 통해 접근 가능
  • 전송: HTTP 요청에 자동으로 포함되지 않음
// Session Storage 사용 예시
sessionStorage.setItem('user', 'john');
const user = sessionStorage.getItem('user');

💡 Session Storage는 서버의 세션과 다른 개념으로, 브라우저 탭이 유지될 때만 데이터가 보존된다.



Local Storage

  • 특징: 브라우저를 닫아도 데이터 유지
  • 범위: 동일 출처(same origin) 내에서 공유
  • 용량: 일반적으로 5MB 정도
  • 접근: JavaScript를 통해 접근 가능
  • 전송: HTTP 요청에 자동으로 포함되지 않음
// Local Storage 사용 예시
localStorage.setItem('theme', 'dark');
const theme = localStorage.getItem('theme');



저장소 선택 시 고려사항

  • 보안성: 민감한 정보는 HttpOnly 쿠키에 저장하는 것이 안전
  • 용량: 대용량 데이터는 Local/Session Storage 사용
  • 자동 전송: 인증 토큰은 요청마다 필요하므로 쿠키가 편리할 수 있음
  • 접근성: JavaScript에서 접근이 필요한 데이터는 Storage API 사용
  • 만료 정책: 데이터 유지 기간에 따라 적절한 저장소 선택

⚡ 토큰(JWT)은 회사 정책에 따라 Local Storage나 쿠키에 저장하는 방식이 다를 수 있다.



인증 방식 비교 (세션-쿠키 vs 토큰)

각 인증 방식은 고유한 특성과 장단점을 가지고 있으므로, 애플리케이션의 요구사항에 맞게 선택해야 한다.

세션-쿠키 vs 토큰 인증

특성 세션-쿠키 인증 토큰 인증
상태 Stateful Stateless
저장 위치 서버(세션 데이터), 클라이언트(세션 ID) 클라이언트
확장성 제한적 우수
보안 서버에 데이터 저장으로 상대적 안전 토큰 자체에 정보 포함, 서명으로 보호
구현 복잡성 낮음 높음
에러 책임 세션 지원 장비 업체 개발자
적합한 환경 단일 도메인, 모놀리식 애플리케이션 분산 시스템, SPA, 모바일 앱


인증 방식의 선택은 애플리케이션의 아키텍처, 보안 요구사항, 확장성 고려사항에 따라 달라질 수 있으며, 때로는 여러 방식을 조합하여 사용하는 하이브리드 접근법이 최적의 솔루션이 될 수 있다.

댓글남기기

참고