diff --git a/Network/Authentication.md b/Network/Authentication.md
new file mode 100644
index 0000000..8649ea4
--- /dev/null
+++ b/Network/Authentication.md
@@ -0,0 +1,453 @@
+# 🍪 쿠키 / 세션 / JWT 완전 정복 스터디 자료
+
+---
+
+## 📋 목차
+
+1. [왜 인증이 필요한가 — Stateless 문제](#1-왜-인증이-필요한가)
+2. [쿠키 (Cookie)](#2-쿠키-cookie)
+3. [세션 (Session)](#3-세션-session)
+4. [JWT (JSON Web Token)](#4-jwt-json-web-token)
+5. [세션 vs JWT 비교 및 선택 기준](#5-세션-vs-jwt)
+6. [Access Token + Refresh Token 전략](#6-access-token--refresh-token)
+7. [면접 단골 질문 & 모범 답변](#7-면접-질문)
+
+---
+
+## 1. 왜 인증이 필요한가
+
+### 1-1. HTTP는 Stateless다
+
+HTTP는 **무상태(Stateless)** 프로토콜이다.  
+서버는 이전 요청을 기억하지 않는다. 매 요청은 완전히 독립적으로 처리된다.
+
+```
+[클라이언트]                    [서버]
+    |--- "나는 홍길동이야, 로그인" -->|  ✅ 인증 성공
+    |                               |
+    |--- "내 장바구니 보여줘" ------->|  ❓ 누구세요?
+    |                               |     (서버는 기억 못함)
+```
+
+> 💡 이것이 바로 **인증(Authentication) 유지 문제**  
+> 로그인했다는 사실을 서버가 계속 알 수 있어야 함 → 쿠키/세션/JWT로 해결
+
+### 1-2. 인증 vs 인가
+
+| 용어 | 영어 | 의미 | 예시 |
+|------|------|------|------|
+| **인증** | Authentication | 네가 누구인지 확인 | 로그인 |
+| **인가** | Authorization | 네가 뭘 할 수 있는지 확인 | 관리자 페이지 접근 권한 |
+
+> 💡 면접에서 자주 혼동됨. 인증 먼저, 인가는 그 다음 단계.
+
+---
+
+## 2. 쿠키 (Cookie)
+
+### 2-1. 쿠키란?
+
+**서버가 클라이언트(브라우저)에 저장하는 작은 데이터 조각**  
+이후 요청마다 브라우저가 자동으로 서버에 쿠키를 전송한다.
+
+```
+[클라이언트]                         [서버]
+    |--- POST /login --------------->|
+    |                                |
+    |<-- Set-Cookie: userId=123 -----|  ← 서버가 쿠키 발급
+    |                                |
+    |--- GET /mypage                 |
+    |    Cookie: userId=123 -------->|  ← 브라우저가 자동으로 전송
+    |                                |  ✅ 서버가 userId=123 확인
+```
+
+### 2-2. 쿠키 속성 (Options)
+
+```http
+Set-Cookie: sessionId=abc123; 
+            Max-Age=3600; 
+            Domain=example.com; 
+            Path=/; 
+            Secure; 
+            HttpOnly; 
+            SameSite=Strict
+```
+
+| 속성 | 설명 |
+|------|------|
+| `Max-Age` / `Expires` | 쿠키 유효기간. 없으면 브라우저 종료 시 삭제 (세션 쿠키) |
+| `Domain` | 쿠키를 전송할 도메인 |
+| `Path` | 쿠키를 전송할 경로 |
+| `Secure` | HTTPS 연결에서만 전송 |
+| `HttpOnly` | JavaScript에서 접근 불가 → XSS 방어 |
+| `SameSite` | 크로스 사이트 요청 시 쿠키 전송 여부 → CSRF 방어 |
+
+### 2-3. SameSite 옵션 상세
+
+| 값 | 동작 |
+|----|------|
+| `Strict` | 같은 사이트 요청에서만 전송. 가장 보안적 |
+| `Lax` | 기본값. 외부 링크로 이동 시 GET 요청에는 전송 |
+| `None` | 모든 요청에 전송 (반드시 `Secure` 함께 사용) |
+
+### 2-4. 쿠키의 보안 취약점
+
+#### XSS (Cross-Site Scripting)
+```
+악성 스크립트: document.cookie  ← HttpOnly 없으면 쿠키 탈취 가능
+대응책: HttpOnly 속성 설정
+```
+
+#### CSRF (Cross-Site Request Forgery)
+```
+상황: 로그인된 사용자가 악성 사이트 방문
+     → 악성 사이트가 몰래 은행 이체 요청 전송
+     → 브라우저가 자동으로 쿠키 첨부
+대응책: SameSite=Strict, CSRF 토큰 사용
+```
+
+### 2-5. 쿠키 저장 위치 비교
+
+| 저장소 | 용량 | 서버 전송 | 유효기간 | JS 접근 |
+|--------|------|-----------|----------|---------|
+| **Cookie** | 4KB | ✅ 자동 | 설정 가능 | 설정 가능 |
+| **LocalStorage** | 5~10MB | ❌ | 영구 | ✅ |
+| **SessionStorage** | 5~10MB | ❌ | 탭 종료 시 | ✅ |
+
+> 💡 인증 토큰을 LocalStorage에 저장하면 XSS에 취약  
+> 민감한 인증 정보는 **HttpOnly 쿠키**에 저장하는 것이 안전
+
+---
+
+## 3. 세션 (Session)
+
+### 3-1. 세션이란?
+
+**서버 측에 사용자 상태를 저장하고, 클라이언트에는 세션 ID만 쿠키로 전달하는 방식**
+
+```
+[클라이언트]                              [서버]                    [세션 저장소]
+    |--- POST /login (ID/PW) ----------->|                              |
+    |                                    |-- 세션 생성 --------------->|
+    |                                    |   { sid: "abc", user: 홍길동 }|
+    |<-- Set-Cookie: sid=abc ------------|                              |
+    |                                    |                              |
+    |--- GET /mypage                     |                              |
+    |    Cookie: sid=abc --------------->|-- 세션 조회 --------------->|
+    |                                    |<-- { user: 홍길동 } --------|
+    |<-- 홍길동의 마이페이지 --------------|                              |
+```
+
+### 3-2. 세션 동작 단계
+
+1. **로그인**: 클라이언트가 아이디/비밀번호 전송
+2. **검증**: 서버가 DB에서 사용자 확인
+3. **세션 생성**: 서버가 고유한 세션 ID 생성 → 세션 저장소에 사용자 정보 저장
+4. **쿠키 발급**: 클라이언트에 세션 ID만 쿠키로 전달
+5. **이후 요청**: 클라이언트가 세션 ID 쿠키를 자동 전송 → 서버가 세션 저장소 조회
+
+### 3-3. 세션 저장소 종류
+
+| 저장소 | 특징 | 단점 |
+|--------|------|------|
+| **서버 메모리** | 가장 빠름, 구현 쉬움 | 서버 재시작 시 소멸, 스케일 아웃 불가 |
+| **DB (MySQL 등)** | 영속성 있음 | 매 요청마다 DB 조회 → 느림 |
+| **Redis** | 빠름 + 영속성 + 공유 가능 | 인프라 추가 필요 |
+
+> 💡 실무에서는 대부분 **Redis**를 세션 저장소로 사용
+
+### 3-4. 세션의 한계 — 스케일 아웃 문제
+
+```
+서버 1대일 때:
+  클라이언트 → 서버A (세션 저장) → 문제없음
+
+서버 여러 대일 때 (로드밸런서):
+  클라이언트 → 로드밸런서 → 서버A (세션 저장)
+  다음 요청   → 로드밸런서 → 서버B (세션 없음!) ← 문제!
+```
+
+**해결 방법:**
+- **Sticky Session**: 같은 클라이언트는 항상 같은 서버로 라우팅 → 로드밸런싱 효율 저하
+- **세션 공유 저장소**: Redis 같은 외부 저장소를 모든 서버가 공유 → 일반적인 해결책
+- **JWT 사용**: 서버에 상태를 저장하지 않음 → Stateless 방식으로 전환
+
+---
+
+## 4. JWT (JSON Web Token)
+
+### 4-1. JWT란?
+
+**사용자 정보를 서버가 아닌 토큰 자체에 담아 클라이언트에 저장하는 방식**  
+서버는 토큰의 유효성만 검증하면 됨 → **Stateless**
+
+```
+세션 방식: 서버가 상태 저장
+JWT 방식:  클라이언트가 토큰(상태) 보관, 서버는 검증만
+```
+
+### 4-2. JWT 구조
+
+JWT는 **`.`(점)으로 구분된 3개의 파트**로 구성된다.
+
+```
+eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
+.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6Iu2Zjeq4uOuPmSIsImlhdCI6MTUxNjIzOTAyMn0
+.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+
+[     Header      ].[        Payload        ].[    Signature    ]
+```
+
+#### Header (헤더)
+```json
+{
+  "alg": "HS256",   // 서명 알고리즘
+  "typ": "JWT"      // 토큰 타입
+}
+```
+
+#### Payload (페이로드)
+```json
+{
+  "sub": "1234567890",     // Subject (사용자 ID)
+  "name": "홍길동",
+  "role": "admin",
+  "iat": 1516239022,       // Issued At (발급 시간)
+  "exp": 1516242622        // Expiration (만료 시간)
+}
+```
+
+> ⚠️ **Payload는 Base64 인코딩만 된 것, 암호화가 아님!**  
+> 누구나 디코딩해서 내용을 볼 수 있음 → 민감한 정보(비밀번호 등) 절대 포함 금지
+
+#### Signature (서명)
+```
+HMACSHA256(
+  base64UrlEncode(header) + "." + base64UrlEncode(payload),
+  secretKey       ← 서버만 알고 있는 비밀키
+)
+```
+
+- 서버의 비밀키로 서명 → 토큰 위변조 감지 가능
+- 클라이언트가 Payload를 수정하면 서명 검증 실패
+
+### 4-3. JWT 동작 흐름
+
+```
+[클라이언트]                         [서버]
+    |--- POST /login (ID/PW) ------->|
+    |                                | 1. 사용자 검증
+    |                                | 2. JWT 생성 (비밀키로 서명)
+    |<-- JWT 토큰 발급 ---------------|
+    |    (클라이언트가 저장)            |
+    |                                |
+    |--- GET /mypage                 |
+    |    Authorization: Bearer {JWT} |
+    |-------------------------------->|
+    |                                | 3. 서명 검증 (비밀키로)
+    |                                | 4. Payload에서 사용자 정보 추출
+    |<-- 마이페이지 데이터 --------------|   (DB 조회 없이!)
+```
+
+### 4-4. JWT 저장 위치
+
+| 저장 위치 | 장점 | 단점 |
+|-----------|------|------|
+| **LocalStorage** | 구현 쉬움 | XSS 공격으로 탈취 가능 |
+| **SessionStorage** | 탭 종료 시 삭제 | XSS 취약, 탭 간 공유 불가 |
+| **HttpOnly Cookie** | XSS 방어 | CSRF 취약 (SameSite로 방어) |
+
+> 💡 보안상 **HttpOnly Cookie**에 저장하는 것이 권장됨  
+> LocalStorage는 편리하지만 XSS에 취약하므로 보안이 중요한 서비스에는 부적합
+
+### 4-5. JWT의 단점
+
+#### 1. 강제 만료 불가
+```
+상황: 사용자가 로그아웃했는데 토큰이 아직 유효기간 내
+     → 탈취된 토큰을 만료 전까지 사용 가능
+
+세션 방식: 세션 삭제 → 즉시 무효화 가능
+JWT 방식:  서버에 저장된 게 없음 → 만료될 때까지 막을 수 없음
+```
+
+**해결 방법:**
+- 토큰 유효기간을 짧게 설정 (5~15분)
+- 블랙리스트 DB에 무효 토큰 저장 → 결국 서버 상태가 생김 (단점 상쇄)
+
+#### 2. Payload 크기
+- 세션: 클라이언트에 ID만 전송 (수십 바이트)
+- JWT: 토큰 자체에 정보 포함 → 요청마다 수백 바이트 추가
+
+#### 3. 비밀키 노출 시 전체 위험
+- 서명에 사용하는 비밀키가 유출되면 모든 토큰 위변조 가능
+
+---
+
+## 5. 세션 vs JWT
+
+### 5-1. 전체 비교표
+
+| 항목 | 세션 | JWT |
+|------|------|-----|
+| 상태 저장 위치 | **서버** (세션 저장소) | **클라이언트** (토큰) |
+| 서버 Stateless | ❌ Stateful | ✅ Stateless |
+| 확장성 | 공유 저장소 필요 | 유리 (서버 간 공유 불필요) |
+| 강제 만료 | ✅ 즉시 가능 | ❌ 어려움 |
+| DB 조회 | 매 요청마다 필요 | 불필요 (서명 검증만) |
+| 보안 | 세션 ID 탈취 위험 | 토큰 탈취 위험 |
+| 토큰 크기 | 작음 (ID만) | 상대적으로 큼 |
+
+### 5-2. 언제 세션을 쓸까?
+
+- **강제 로그아웃이 중요한 서비스** (금융, 보안 민감 서비스)
+- **서버 수가 적고 트래픽이 많지 않은 서비스**
+- **사용자 상태를 실시간으로 제어해야 하는 경우** (관리자가 특정 계정 강제 종료 등)
+
+### 5-3. 언제 JWT를 쓸까?
+
+- **마이크로서비스 아키텍처** (여러 서버가 토큰만 검증하면 됨)
+- **서버 스케일 아웃이 잦은 서비스**
+- **모바일 앱** (쿠키 관리보다 토큰 관리가 편리)
+- **외부 서비스와의 API 연동** (OAuth 등)
+
+---
+
+## 6. Access Token + Refresh Token
+
+### 6-1. 왜 두 종류의 토큰이 필요한가?
+
+JWT의 강제 만료 문제를 완화하기 위한 전략.
+
+```
+Access Token  : 유효기간 짧음 (5~15분) — 실제 API 요청에 사용
+Refresh Token : 유효기간 김 (7~30일)  — Access Token 재발급에만 사용
+```
+
+- Access Token 탈취당해도 → 빠르게 만료됨 (피해 최소화)
+- Refresh Token으로 재발급 → 사용자가 자주 로그인 안 해도 됨
+
+### 6-2. 전체 동작 흐름
+
+```
+[클라이언트]                              [서버]
+    |--- POST /login (ID/PW) ----------->|
+    |<-- Access Token (15분)             |
+    |    Refresh Token (7일) ------------|
+    |                                    |
+    |--- GET /api (Access Token) ------->| ✅ 정상 응답
+    |--- GET /api (Access Token) ------->| ✅ 정상 응답
+    |       ...15분 후...                 |
+    |--- GET /api (만료된 Access Token) ->| ❌ 401 반환
+    |                                    |
+    |--- POST /refresh (Refresh Token) ->| Refresh Token 검증
+    |<-- 새로운 Access Token -------------|
+    |                                    |
+    |--- GET /api (새 Access Token) ----->| ✅ 정상 응답
+```
+
+### 6-3. Refresh Token 보안 전략
+
+#### Refresh Token Rotation
+- Refresh Token을 사용할 때마다 새로운 Refresh Token 발급
+- 이전 Refresh Token은 즉시 무효화
+- → 탈취된 Refresh Token 재사용 감지 가능
+
+```
+정상 흐름:
+  RT-1 사용 → RT-2 발급, RT-1 무효화
+  RT-2 사용 → RT-3 발급, RT-2 무효화
+
+탈취 감지:
+  RT-2 사용 → RT-3 발급
+  공격자가 RT-2로 재시도 → 이미 무효화된 RT-2 사용 감지!
+  → 모든 세션 강제 종료
+```
+
+#### Refresh Token 저장 위치
+- 서버 DB 또는 Redis에 저장 (화이트리스트 방식)
+- 클라이언트에는 HttpOnly Cookie로 전달
+
+### 6-4. 로그아웃 처리
+
+| 방식 | 처리 |
+|------|------|
+| 세션 | 서버에서 세션 삭제 → 즉시 무효화 |
+| JWT | Access Token 짧게 만료 대기 + Refresh Token 블랙리스트 등록 |
+
+---
+
+## 7. 면접 질문
+
+### Q1. 쿠키와 세션의 차이점은?
+
+**모범 답변:**
+> 쿠키는 상태 정보를 클라이언트(브라우저)에 저장하고, 세션은 서버에 저장합니다. 쿠키는 클라이언트에 직접 데이터가 있어 탈취 위험이 있지만, 세션은 서버에 데이터가 있고 클라이언트에는 세션 ID만 전달하므로 상대적으로 안전합니다. 다만 세션은 서버 메모리를 사용하므로 사용자가 많아질수록 부담이 됩니다.
+
+---
+
+### Q2. JWT의 구조를 설명해보세요.
+
+**모범 답변:**
+> JWT는 Header, Payload, Signature 세 부분이 점(.)으로 연결된 구조입니다. Header에는 알고리즘과 토큰 타입, Payload에는 사용자 정보와 만료 시간 등의 클레임이 담깁니다. Signature는 Header와 Payload를 서버의 비밀키로 서명한 값으로, 이를 통해 토큰의 위변조 여부를 검증합니다. Payload는 암호화가 아닌 Base64 인코딩이므로 민감한 정보를 담으면 안 됩니다.
+
+---
+
+### Q3. 세션 vs JWT, 언제 뭘 사용하나요?
+
+**모범 답변:**
+> 강제 로그아웃이나 실시간 세션 제어가 필요한 금융/보안 서비스는 세션이 적합합니다. 반면 마이크로서비스처럼 여러 서버가 인증 정보를 공유해야 하거나 수평 확장이 잦은 경우는 JWT가 유리합니다. JWT는 Stateless라 서버 간 세션 공유 문제가 없기 때문입니다. 실무에서는 두 방식을 조합하기도 합니다.
+
+---
+
+### Q4. JWT를 서버에서 강제 만료시키려면 어떻게 하나요?
+
+**모범 답변:**
+> JWT는 기본적으로 서버에 상태가 없어 강제 만료가 어렵습니다. 해결 방법으로는 첫째, Access Token 유효기간을 짧게 (5~15분) 설정하고 Refresh Token으로 재발급하는 방식이 있습니다. 둘째, 로그아웃 시 해당 토큰을 DB나 Redis의 블랙리스트에 등록하고 매 요청마다 확인하는 방법이 있습니다. 다만 두 번째 방식은 서버에 상태가 생기므로 Stateless의 장점이 일부 사라집니다.
+
+---
+
+### Q5. Access Token과 Refresh Token의 차이는?
+
+**모범 답변:**
+> Access Token은 유효기간이 짧고(5~15분) 실제 API 요청 시 사용됩니다. Refresh Token은 유효기간이 길고(7~30일) Access Token이 만료됐을 때 재발급 받는 용도로만 사용됩니다. Access Token이 탈취되더라도 짧은 시간 내에 만료되므로 피해를 최소화할 수 있습니다. Refresh Token은 보안을 위해 HttpOnly Cookie나 서버 DB에 안전하게 저장합니다.
+
+---
+
+### Q6. XSS와 CSRF가 무엇이고 어떻게 방어하나요?
+
+**모범 답변:**
+> XSS는 공격자가 악성 스크립트를 삽입해 사용자의 브라우저에서 실행되는 공격입니다. 쿠키의 HttpOnly 속성과 Content Security Policy로 방어합니다. CSRF는 사용자가 의도하지 않은 요청을 몰래 보내게 하는 공격으로, 브라우저가 쿠키를 자동 전송하는 특성을 악용합니다. SameSite 쿠키 속성과 CSRF 토큰으로 방어합니다.
+
+---
+
+### Q7. 쿠키를 LocalStorage 대신 사용하는 이유는?
+
+**모범 답변:**
+> 인증 토큰을 LocalStorage에 저장하면 JavaScript로 접근할 수 있어 XSS 공격에 취약합니다. 반면 HttpOnly 속성을 가진 쿠키는 JavaScript에서 접근이 불가능해 XSS로부터 토큰을 보호할 수 있습니다. 대신 CSRF 공격에 노출될 수 있으므로 SameSite 속성과 CSRF 토큰을 함께 사용합니다.
+
+---
+
+## 📌 핵심 요약 카드
+
+```
+Stateless  = HTTP는 상태를 기억 못함 → 인증 유지 수단 필요
+
+쿠키       = 서버가 브라우저에 저장하는 작은 데이터
+             HttpOnly(XSS 방어) + SameSite(CSRF 방어)
+
+세션       = 서버가 상태 저장, 클라이언트는 세션 ID만 보관
+             강제 만료 ✅ | 스케일 아웃 어려움 ⚠️
+
+JWT        = 클라이언트가 토큰(상태) 보관, 서버는 검증만
+             Header.Payload.Signature 구조
+             Payload = Base64 인코딩 (암호화 ❌)
+             Stateless ✅ | 강제 만료 어려움 ⚠️
+
+Access + Refresh = 짧은 수명(Access) + 긴 수명(Refresh)
+                   탈취 피해 최소화 + 사용자 경험 유지
+```
+
+---
+
+*참고: HTTP/HTTPS 스터디 자료와 함께 보면 더 이해가 잘 됨 | 면접 스터디용*