Cookie-Based Auth vs. Basic Authentication

Cookie-Based Auth vs. Basic Authentication

쿠키 기반 인증(Cookie-Based Authentication)

작동 원리

쿠키 기반 인증은 HTTP 쿠키를 사용하여 사용자의 인증 상태를 유지하는 방식이다.

일반적인 흐름은 다음과 같다:

1. 사용자가 로그인 폼에 자격 증명(사용자 이름과 비밀번호)을 입력한다.
2. 서버는 자격 증명을 검증하고, 인증에 성공하면 세션 ID를 생성한다.
3. 서버는 이 세션 ID를 쿠키로 클라이언트에게 전송한다 (Set-Cookie 헤더 사용).
4. 브라우저는 해당 도메인에 대한 후속 요청에 이 쿠키를 자동으로 포함시킨다.
5. 서버는 쿠키에 포함된 세션 ID를 검증하여 사용자를 식별한다.

장점

• 사용자 경험: 사용자가 자격 증명을 한 번만 입력하면 되므로 편리하다.
• 상태 관리: 서버 측에서 세션 상태를 유지할 수 있어 세밀한 제어가 가능하다.
• 보안 옵션: HttpOnly, Secure, SameSite 등의 플래그를 통해 보안을 강화할 수 있다.
• 만료 및 갱신: 세션 타임아웃과 자동 갱신 메커니즘을 구현할 수 있다.
• 로그아웃: 서버에서 세션을 무효화하여 즉시 로그아웃이 가능하다.

단점

• CSRF 취약점: 적절한 보호 조치 없이는 사이트 간 요청 위조(CSRF) 공격에 취약할 수 있다.
• 확장성 문제: 세션 데이터를 서버에 저장하면 분산 시스템에서 확장성 문제가 발생할 수 있다.
• 도메인 제한: 쿠키는 기본적으로 단일 도메인에 제한되어 있어 크로스 도메인 요청에 제약이 있다.
• 모바일 앱 호환성: 일부 모바일 앱 환경에서는 쿠키 관리가 복잡할 수 있다.

기본 인증(Basic Authentication)

작동 원리

기본 인증은 HTTP 프로토콜에 내장된 간단한 인증 메커니즘이다:

1. 클라이언트가 보호된 리소스에 접근을 시도한다.
2. 서버는 401 Unauthorized 응답과 함께 “WWW-Authenticate: Basic” 헤더를 반환한다.
3. 브라우저는 사용자에게 자격 증명을 요청하는 팝업을 표시한다.
4. 사용자가 자격 증명을 입력하면, 브라우저는 사용자 이름과 비밀번호를 콜론으로 결합하고 Base64로 인코딩한다.
5. 브라우저는 “Authorization: Basic [인코딩된 자격 증명]” 헤더와 함께 요청을 재전송한다.
6. 서버는 자격 증명을 확인하고 유효하면 요청된 리소스에 접근을 허용한다.

장점

• 단순성: 구현이 매우 간단하며 HTTP 프로토콜에 내장되어 있다.
• 무상태: 서버에 상태를 저장할 필요가 없어 확장성이 좋다.
• 범용성: 거의 모든 HTTP 클라이언트와 서버에서 지원된다.
• API 접근: REST API와 같은 프로그래밍 인터페이스에 적합하다.
• 프록시 호환성: 대부분의 프록시 서버와 함께 작동한다.

단점

• 보안 취약점: 자격 증명이 Base64로만 인코딩되어 쉽게 디코딩될 수 있다. HTTPS 사용이 필수적이다.
• 자격 증명 관리: 모든 요청마다 자격 증명을 전송해야 한다.
• 로그아웃 메커니즘 부재: 표준화된 로그아웃 방법이 없어 브라우저를 닫거나 다른 자격 증명으로 덮어쓰는 방법밖에 없다.
• 사용자 경험: 브라우저의 기본 팝업은 사용자 경험이 좋지 않으며 커스터마이징이 어렵다.
• 중간자 공격 위험: HTTPS를 사용하지 않으면 자격 증명이 평문으로 노출될 위험이 있다.

토큰 기반 인증과의 관계

현대 웹 애플리케이션에서는 쿠키 기반 인증과 기본 인증 외에도 JWT(JSON Web Token)와 같은 토큰 기반 인증이 널리 사용된다.

토큰 기반 인증은 다음과 같은 특징이 있다:

• 토큰은 쿠키나 Authorization 헤더를 통해 전송될 수 있다.
• 상태를 서버에 저장하지 않는 무상태(stateless) 인증 방식이다.
• 토큰 자체에 사용자 정보와 권한을 포함할 수 있다.
• 크로스 도메인 요청에 적합하다.

쿠키 기반 인증에서는 세션 ID 대신 JWT와 같은 토큰을 쿠키에 저장하는 하이브리드 접근 방식이 점점 더 많이 사용되고 있다.

사용 사례 비교

• 쿠키 기반 인증에 적합한 경우
  • 웹 애플리케이션과 사용자 중심 서비스
  • 풍부한 사용자 경험이 필요한 경우
  • 세션 관리와 상태 유지가 중요한 경우
  • 서버 측에서 세션을 제어해야 하는 경우
• 기본 인증에 적합한 경우
  • 간단한 API나 내부 서비스
  • 개발 환경이나 테스트 목적
  • 레거시 시스템 통합
  • 단순한 관리 인터페이스
  • 머신-투-머신(M2M) 통신

보안 고려 사항

• 쿠키 기반 인증의 보안 강화
  • HTTPS 사용 필수
  • Secure 플래그: HTTPS를 통해서만 쿠키 전송
  • HttpOnly 플래그: JavaScript에서 쿠키 접근 방지
  • SameSite 플래그: CSRF 공격 방지
  • 적절한 만료 시간 설정
  • CSRF 토큰 구현
• 기본 인증의 보안 강화
  • HTTPS 사용 필수
  • 자격 증명 캐싱 제한
  • IP 기반 접근 제한
  • 요청 비율 제한(Rate limiting)
  • 추가 인증 레이어 구현(예: API 키)

구현 복잡성

쿠키 기반 인증은 일반적으로 다음과 같은 구성 요소가 필요하다:

• 사용자 저장소(데이터베이스)
• 세션 관리 시스템
• 쿠키 처리 로직
• 로그인/로그아웃 페이지
• CSRF 보호 메커니즘

기본 인증은 더 간단하며 다음만 필요하다:

• 사용자 저장소(데이터베이스 또는 설정 파일)
• 기본 인증 헤더 처리 로직

성능 영향

• 쿠키 기반 인증
  • 세션 조회 오버헤드
  • 세션 저장소 확장성 문제
  • 상대적으로 작은 헤더 크기
  • 분산 시스템에서 세션 공유 문제
• 기본 인증
  • 모든 요청마다 자격 증명 검증 필요
  • 헤더 크기가 상대적으로 클 수 있음
  • 캐싱을 통한 성능 최적화 가능성
  • 분산 시스템에서 쉽게 확장 가능

Cookie-Based Auth vs. Basic Authentication

현대적인 접근 방식과 권장 사항

현대 웹 개발에서는 이러한 전통적인 인증 방식에서 발전한 하이브리드 접근 방식이 많이 사용된다:

1. JWT in 쿠키: JWT 토큰을 쿠키에 저장하여 쿠키의 편의성과 JWT의 무상태성 결합
2. OAuth 2.0 / OpenID Connect: 소셜 로그인 및 권한 위임에 표준화된 프레임워크 제공
3. 다중 요소 인증(MFA): 기본 인증이나 쿠키 기반 인증에 추가적인 보안 레이어 제공

각 인증 방식을 선택할 때 고려해야 할 주요 사항:

• 보안 요구 사항: 보호해야 할 데이터의 민감도
• 사용자 경험: 대상 사용자와 애플리케이션 유형
• 확장성 요구 사항: 현재 및 미래의 트래픽 수준
• 구현 복잡성: 개발 리소스와 타임라인
• 호환성 요구 사항: 지원해야 하는 클라이언트 유형

용어 정리

참고 및 출처