Authentication (Session, Token), Middleware

22 Mar 2025 in Study Archive / CS

⚠️ 안내: 이 글은 학습 기록용입니다. 오류나 보완 의견은 댓글로 알려주세요.

1. 인증(Authentication)

인증(Authentication)은 “이 요청을 보낸 주체가 누구인지 확인하는 과정”

• 권한(Authorization)과는 다른 개념
• 인증(Authentication)은 “누구인가?” 를 확인하는 단계
• 권한(Authorization)은 “무엇을 할 수 있는가?” 를 판단하는 단계

1-1. HTTP의 stateless

• HTTP는 요청 간 상태를 저장하지 않음
• 즉, 서버는 원칙적으로 “이 요청이 이전 요청과 같은 사용자로부터 왔는지” 알 수 없음
• 인증 상태를 어디에 두는지에 따른 인증 전략
  • 서버가 인증 상태를 저장 -> Session 기반
  • 서버에 인증 상태를 저장하지 않고, 클라이언트가 서명된 증명서를 제출 -> Token 기반
• 증거(Session ID/토큰)을 주고 받는 방식
  • Cookie: 브라우저가 자동 첨부, Session기반 인증에서 많이 사용
  • Authorization Header(Bearer): 클라이언트가 HTTP 요청 헤더에 명시적으로 첨부, Token 기반 인증에서 많이 사용

1-2. Session 기반 인증

기본 개념

• Session 인증은 보통 “Session Cookie + Server-side Session”의 조합을 많이 사용
  • Cookie: 브라우저가 저장하고 요청마다 자동 전송하는 데이터(클라이언트 저장소에 있음)
  • Session: 서버가 저장하는 사용자 상태 데이터(서버 저장소에 있음)
  • Session Cookie: 쿠키에 “세션을 식별하는 값(Session ID)”을 넣어 보관하는 방식
• 쿠키에 “인증 정보 자체”를 넣는 것이 아니라 “서버 Session”을 가리키는 “키(Session ID)”를 넣는 것

동작흐름

1. 사용자가 로그인 요청
2. 서버가 자격 증명 검증 성공
3. 서버가 세션 저장소에 세션 생성 (예: {user_id, login_time, …})
4. 서버가 Session ID 발급
5. 응답의 set-cookie로 Session ID 전달
6. 이후 요청마다 브라우저가 해당 쿠키를 자동 전송
7. 서버는 Session ID로 세션을 조회하고 사용자 식별

Session의 특징

장점	단점
서버가 인증 상태를 완전히 통제함 (강제 로그아웃·세션 무효화가 명확)	서버가 상태를 저장해야 함 (메모리·db·Redis 등 → 인프라 복잡도 증가)
클라이언트에 인증 값이 장기간 남지 않음 (세션 만료 정책 중심)	수평 확장 시 세션 공유 문제 발생 (sticky session 또는 중앙 세션 저장소 필요)
SSR·어드민 등 전통적인 브라우저 기반 웹 앱에 구현·운영이 용이	쿠키 자동 전송 특성으로 CSRF 등 공격면을 고려해야 함 (별도 방어 전략 필요)
세션을 서버에서 즉시 무효화할 수 있음 (침해 감지 시 전 세션 강제 종료 가능)	세션 쿠키 탈취 시 세션 하이재킹으로 즉시 권한 탈취 가능 (xss·보안 옵션 미흡 시 치명적)

• 세션 기반 인증은 세션 쿠키가 탈취될 경우 위험하다는 명확한 단점이 있지만, 반대로 서버가 세션 상태를 직접 통제할 수 있기 때문에 침해 인지 이후의 대응력은 JWT보다 훨씬 강력
• 특히 강제 로그아웃, 세션 일괄 무효화, 조건부 세션 차단과 같은 조치는 세션 기반 인증에서만 실질적으로 가능한 보안 통제 수단

1-3. Token 기반 인증

• 서버가 로그인 상태를 직접 저장하지 않고, 클라이언트가 토큰을 보관하여 요청마다 제출하는 방식
• 서버는 요청에 포함된 토큰을 검증함으로써 사용자를 식별한다.
• 대표적인 구현이 JWT (JSON web token)

JWT (JSON web token)

• JWT는 아래와 같은 구조를 가짐
  • Header: 토큰 타입/서명 알고리즘 정보
  • Payload: 클레임(claims) — 사용자 식별자, 만료 시간 등
  • Signature: 위 내용을 비밀키(또는 개인키)로 서명한 값(위·변조 검사에 사용)
• 서버가 토큰을 저장하는 것이 아닌, 클라이언트가 요청 시 JWT를 제출하고 서버는 서명(Signature) 검증 + 만료 검증으로 진위를 판단

동작방식

1. 사용자가 로그인 요청
2. 서버가 자격 증명 검증 성공
3. 서버가 사용자 정보를 기반으로 JWT를 생성 (예: user_id, role, exp 등 클레임 포함)
4. 서버가 JWT를 발급 (서명된 토큰, 서버는 별도 세션 저장소를 생성하지 않음)
5. 응답으로 JWT 전달
6. 이후 요청마다 클라이언트가 JWT를 포함하여 요청 전송 (예: Bearer 또는 쿠키 자동 전송)
7. 서버는 요청에 포함된 JWT를 검증하여 사용자 식별
8. 서명 검증, 만료 시간(exp) 확인, 클레임 기반 사용자/권한 판별

JWT 의 특징

장점	단점
서버가 세션 상태를 크게 들고 있지 않아도 됨 → 수평 확장에 유리	토큰 탈취 시 만료 전까지 악용될 수 있음 (access token 수명이 길수록 위험)
모바일·외부 API·서드파티 클라이언트 등 브라우저 외 환경과 궁합이 좋음	강제 로그아웃·권한 회수·즉시 무효화가 세션보다 복잡함 (추가 전략 필요)
인증이 API 요청 단위로 명확함 (Authorization 헤더 기반 표준적 설계)	페이로드는 암호화가 아닌 서명 기반이므로 민감 정보 포함 시 보안 사고 위험

• 토큰 기반 인증은 서버 상태를 최소화하여 확장성과 범용성이 뛰어나지만, 토큰 탈취 이후의 통제력은 세션 기반 인증보다 약하다는 구조적 한계가 있음
• access / refresh token 분리, 짧은 수명, 재발급 전략이 필수적

1-4. Session과 Token, 언제 쓰는 것이 좋을까?

JWT가 특히 잘 맞는 경우	Session이 더 단순하고 강력한 경우
API 중심 아키텍처 (프론트/백 분리), 모바일 앱, 외부·서드파티 클라이언트 지원	SSR 기반 웹 앱, 내부 어드민, 전통적인 웹 서비스
수평 확장 또는 마이크로서비스 구조로 운영될 가능성이 높음	단일 서비스 또는 제한된 확장 구조
인증 정보가 여러 도메인·플랫폼에서 재사용되어야 함	동일 도메인 내 사용자 인증이 중심
세션 공유/중앙 세션 저장소 운영 비용을 줄이고 싶음	서버가 로그인 상태를 직접 통제하는 것이 중요함
Authorization 헤더 기반의 명확한 API 인증 모델이 필요함	강제 로그아웃·즉시 무효화가 빈번하게 요구됨
무상태(Stateless) 인증을 통한 인프라 단순화가 목적	보안 사고 발생 시 서버 주도의 즉각적 대응이 중요

2. Middleware

2-1. 개념

• Middleware는 요청(request)과 응답(response) 사이에 있는 처리 계층
• 아래와 같은 엔드포인트마다 반복되면 안 되는 공통 관심사(cross-cutting concern) 들은, middleware에서 일괄 처리하는 것이 적절
  • 인증(Authentication) / 인가(Authorization)
  • 요청·응답 로깅
  • 요청 데이터 전처리 / 응답 데이터 후처리
  • 보안 관련 처리(CORS, 헤더 설정 등)
  • 에러 처리 및 공통 예외 관리
• 예를 들어, 인증이 필요한 페이지에 접근할 때,
  • Middleware가 요청을 가로채 사용자의 인증 상태를 확인하고
  • 인증되지 않은 경우, 서버 로직에 도달시키지 않고 로그인 페이지로 리다이렉트함

2-2. Middleware가 필요한 이유

• 웹 환경에서는 하나의 서버가 다수의 클라이언트 요청을 동시에 처리한다.
  • 서버는 제한된 자원을 가진 단일 시스템
  • 클라이언트는 수백, 수천 개의 동시 요청을 보낼 수 있음
• 이때 모든 요청을 곧바로 비즈니스 로직에서 처리하면 불필요한 연산이 증가하고 서버 자원이 낭비되며 코드 중복 생김
• 따라서 Middleware는 인증되지 않은 요청을 초기에 차단하고 반복적인 공통 작업을 한 곳에서 처리 서버의 핵심 로직이 “필요한 요청만” 처리하도록 도움

2-3. 서버 Middleware vs 클라이언트 Middleware

구분	서버 미들웨어 (Server-side Middleware)	클라이언트 미들웨어 (Client-side Middleware)
실행 위치	서버에서 실행	클라이언트(브라우저·앱)에서 실행
실행 시점	요청이 서버 비즈니스 로직에 도달하기 전	요청 전 또는 응답 수신 후
주요 역할	요청 전처리 및 서버 로직 진입 제어	요청 구성 자동화 및 응답 후처리
관심사	서버 로직 보호, 일관된 처리 규칙 적용	사용자 경험(UX), 개발 편의성
책임 주체	서버 애플리케이션	클라이언트 애플리케이션
재사용 범위	서버 전체 또는 특정 API 범위	특정 화면·기능·API 호출 단위
대표 예시	인증 상태 확인 요청 유효성 검사 불필요한 요청 차단	인증 헤더 자동 주입 요청·응답 포맷 변환 에러 공통 처리
우회 가능성	클라이언트에서 직접 우회 불가	사용자가 직접 요청을 만들면 우회 가능
변경 영향도	변경 시 모든 클라이언트에 즉시 반영	변경 시 클라이언트 배포 필요

• 서버 Middleware는 서버 입장에서 요청을 어떻게 받아들일지 정의하고, 클라이언트 Middleware는 요청을 어떻게 만들고 해석할지를 담당

2-4. Django의 Middleware

Django의 요청 처리 흐름

client
  ↓
middleware (요청 단계에서 선처리)
  ↓
view (비즈니스 로직)
  ↓
middleware (응답 단계에서 후처리)
  ↓
client

Django가 기본으로 제공하는 대표적인 미들웨어

• Django는 아래와 같이 기본적으로 필요한 기능을 기본 미들웨어로 구현해둠
  • securitymiddleware: HTTPS 리다이렉트, 보안 헤더 설정 등
  • sessionmiddleware:쿠키 기반 세션 관리
  • authenticationmiddleware: 세션을 기반으로 request.user 구성
  • csrfviewmiddleware: CSRF 공격 방어
  • commonmiddleware: URL 정규화, 공통 요청 처리
• Django의 기본 미들웨어는 HTTP + Session 기반을 전제로 설계되어 있음
• 따라서, JWT 기반 인증, WebSocket(ASGI) 환경, 세션을 사용하지 않는 API 중심 아키텍처에서 커스텀 미들웨어를 직접 구현해야할 수도 있음