Token Authentication vs. Cookie-Based Auth
토큰 인증(Token Authentication)
토큰 인증은 서버가 사용자의 인증 정보를 확인한 후 서명된 토큰을 발급하고, 클라이언트가 이 토큰을 이후의 요청에 포함시켜 자신을 인증하는 방식이다. 가장 널리 사용되는 토큰 형식은 JWT(JSON Web Token)이다.
작동 방식
- 사용자가 자격 증명(사용자 이름/비밀번호)을 서버에 제출한다.
- 서버는 자격 증명을 검증하고, 사용자 식별자와 권한 정보를 포함한 토큰을 생성한다.
- 서버는 비밀 키로 토큰에 서명하여 클라이언트에게 반환한다.
- 클라이언트는 이 토큰을 저장하고(주로 로컬 스토리지, 세션 스토리지 또는 메모리에 저장), 이후 요청의 Authorization 헤더에 포함시킨다.
- 서버는 토큰의 서명을 검증하고, 포함된 정보를 기반으로 사용자를 인증한다.
특징
- 무상태(Stateless): 서버는 클라이언트 상태 정보를 저장하지 않는다.
- 확장성: 여러 서버 간에 인증 정보를 공유할 필요가 없다.
- 플랫폼 독립적: 모바일 앱, SPA, API 등 다양한 클라이언트에서 사용 가능하다.
- 보안: 토큰에 서명을 통해 변조를 방지한다.
- 만료 시간 설정 가능: 토큰에 만료 시간을 포함할 수 있다.
쿠키 기반 인증(Cookie-Based Authentication)
쿠키 기반 인증은 서버가 사용자 인증 후 세션 ID를 포함한 쿠키를 클라이언트에 전송하고, 클라이언트가 이 쿠키를 모든 요청에 자동으로 포함시켜 인증하는 방식이다.
작동 방식
- 사용자가 자격 증명을 서버에 제출한다.
- 서버는 자격 증명을 검증하고, 세션 ID를 생성한 후 서버 측(데이터베이스, 캐시 등)에 이 ID와 사용자 정보를 연결하여 저장한다.
- 서버는 세션 ID를 포함한 쿠키를 클라이언트에게 전송한다.
- 클라이언트의 브라우저는 자동으로 해당 도메인에 대한 모든 요청에 이 쿠키를 포함시킨다.
- 서버는 쿠키에서 세션 ID를 추출하고, 저장된 세션 정보를 조회하여 사용자를 인증한다.
특징
- 상태 유지(Stateful): 서버는 세션 정보를 저장하여 클라이언트 상태를 유지한다.
- 브라우저 통합: 모든 주요 브라우저에서 기본적으로 지원한다.
- 보안 옵션: HttpOnly, Secure, SameSite 등의 옵션으로 보안 강화 가능한다.
- 자동 전송: 사용자가 명시적으로 코드를 작성하지 않아도 쿠키가 자동으로 전송된다.
- 도메인 제한: 쿠키는 특정 도메인에 제한될 수 있다.
장단점
토큰 인증의 장단점
장점:
- 서버 확장성이 우수하다: 무상태 특성으로 수평적 확장이 용이하다.
- 다양한 도메인 및 서비스 간 인증에 유용하다(마이크로서비스 아키텍처).
- 모바일 앱 및 API 통합이 쉽다.
- 서버 측 저장소가 필요 없어 리소스 효율성이 높다.
- 토큰에 사용자 정보와 권한을 포함할 수 있어 데이터베이스 조회 횟수를 줄일 수 있다.
단점:
- 토큰 크기가 클 수 있어 네트워크 오버헤드가 발생한다.
- 토큰 철회가 어렵다(발급된 토큰은 만료될 때까지 유효).
- 민감한 정보 유출 위험이 있다(로컬 스토리지 저장 시).
- JWT 사용 시 잘못된 구현으로 인한 보안 취약점이 발생할 수 있다.
- 토큰 갱신 메커니즘의 구현이 복잡할 수 있다.
쿠키 기반 인증의 장단점
장점:
- 구현이 간단하고 대부분의 웹 프레임워크에서 기본 지원한다.
- 세션을 언제든지 무효화할 수 있다.
- HttpOnly 플래그로 XSS 공격으로부터 보호할 수 있다.
- 쿠키 크기가 작아 네트워크 오버헤드가 적다.
- 사용자 데이터를 서버에 안전하게 보관할 수 있다.
단점:
- 서버 측 세션 저장소가 필요하여 자원을 소비한다.
- 다중 서버 환경에서는 세션 동기화가 필요하다.
- CSRF(Cross-Site Request Forgery) 공격에 취약할 수 있다.
- 크로스 도메인 요청 처리가 복잡하다.
- 모바일 앱이나 SPA에서 구현이 더 복잡할 수 있다.
사용 시나리오 및 선택 가이드
토큰 인증이 적합한 경우
- 마이크로서비스 아키텍처
- 서버리스 함수
- 모바일 애플리케이션
- 단일 페이지 애플리케이션(SPA)
- RESTful API
- 크로스 도메인 요청이 많은 서비스
쿠키 기반 인증이 적합한 경우
- 전통적인 웹 애플리케이션(서버 렌더링)
- 단일 도메인 내에서 운영되는 서비스
- 세션 관리가 중요한 애플리케이션
- 높은 보안이 요구되는 애플리케이션(은행, 금융 서비스)
- 사용자 활동 추적이 필요한 경우
최신 동향 및 하이브리드 접근법
최근에는 두 방식의 장점을 결합한 하이브리드 접근법이 증가하고 있다:
- 토큰 기반 세션 관리: JWT를 사용하되 서버 측에서도 토큰 정보를 유지하여 즉시 철회 가능하게 한다.
- 쿠키에 저장된 JWT: 토큰의 장점을 유지하면서 HttpOnly 쿠키에 저장하여 XSS 공격으로부터 보호한다.
- 리프레시 토큰 + 액세스 토큰 패턴: 짧은 수명의 액세스 토큰과 더 긴 수명의 리프레시 토큰을 함께 사용하여 보안과 사용자 경험을 개선한다.
- SameSite 속성: 최신 브라우저에서 지원하는 SameSite 쿠키 속성을 활용하여 CSRF 공격 위험을 줄인다.
Token Authentication vs. Cookie-Based Auth 비교
| 특성 | 토큰 기반 인증 | 쿠키 기반 인증 |
|---|---|---|
| 상태 관리 | 무상태(Stateless) | 상태 유지(Stateful) |
| 서버 저장소 | 필요 없음 | 필요함(세션 저장) |
| 확장성 | 높음 | 낮음(세션 클러스터링 필요) |
| 클라이언트 저장 위치 | 로컬/세션 스토리지, 메모리 | 브라우저 쿠키 |
| 전송 방식 | Authorization 헤더 | 자동(쿠키 헤더) |
| 크기 제한 | 상대적으로 큼(특히 JWT) | 일반적으로 4KB 이하 |
| CORS 지원 | 용이함 | 복잡함(withCredentials 설정 필요) |
| 모바일/API 호환성 | 우수함 | 제한적 |
| 만료 처리 | 자체 포함(토큰 내 만료 시간) | 서버 측 제어 |
| 취소 가능성 | 어려움(블랙리스트 필요) | 용이함(세션 삭제) |
| XSS 취약성 | 높음(로컬 스토리지 사용 시) | 중간(HttpOnly 옵션으로 완화 가능) |
| CSRF 취약성 | 낮음 | 높음(대응책 필요) |
| 서버 오버헤드 | 낮음(검증만 필요) | 높음(세션 관리) |
| 구현 복잡성 | 중간 | 낮음(프레임워크 지원) |
| 자원 사용량 | 클라이언트 측 높음(큰 토큰) | 서버 측 높음(세션 저장) |
| microservices 적합성 | 높음 | 낮음 |
| 오프라인 접근 | 가능(토큰 저장 시) | 불가능 |
용어 정리
| 용어 | 설명 |
|---|---|