[10주차/메이] 워크북 제출합니다.

keyword/chapter10/keyword.md

@@ -0,0 +1,119 @@
+- **Spring Security**
+
+    : 스프링 기반 보안 프레임워크
+
+    - 웹 애플리케이션에서 보안은 로그인, 권한, 세션 관리 등 매우 중요한 요소인데, 이를 쉽게 처리할 수 있도록 다양한 기능을 제공
+
+        특히, 스프링 MVC와 독립적으로 동작하며, 필터 기반 아키텍처로 설계되어있음
+
+    - 특징
+        - **인증 (Authentication)**
+
+            확장성, 유연성 확보
+
+            - 폼 기반 로그인 (우리가 일반적으로 보는 로그인 화면)
+            - HTTP Basic 인증 (API에서 종종 사용됨)
+            - 소셜 로그인 (구글, 페이스북 등 OAuth)
+            - LDAP (기업 사내 시스템 연동)
+            - JWT, OAuth2 등 토큰 기반 인증
+        - **인가 (Authorization)**
+            - 애플리케이션의 리소스 접근 권한을 관리
+
+                특정 사용자 또는 그룹(Role)에 대해 권한을 설정하여 리소스 접근을 제어
+
+                ex) 일반 사용자는 `/user`만 접근 가능하고, 관리자는 `/admin`도 접근 가능하도록 제한 가
+
+        - **세션(Session) 관리**
+            - 로그인 상태 유지
+            - 세션 만료 시간 설정
+            - 다중 로그인 제어
+        - CSRF 방어 : CSRF(Cross-Site Request Forgery) 공격은 사용자가 인증된 상태에서 악의적인 요청을 보내는 것을 유도하는 공격
+
+            스프링 시큐리티는 CSRF 방어 기능을 기본적으로 제공하여 예방
+
+        - 보안 이벤트 로깅 : 보안 관련 이벤트를 로깅하여 관리자와 개발자가 인증 및 권한 부여 과정을 추적할 수 있도록 도움
+        - 필터 기반 아키텍처 : 필터 체인(Filter Chain)을 기반으로 동작
+
+            필터 체인 : 웹 요청이 서버에 도달하기 전에 여러 보안 필터들이 차례로 검사
+
+            클라이언트 요청이 서버로 도달하기 전에 다양한 보안 필터를 거쳐 보안 검사를 수행
+
+        - 사용자 정의 보안 로직 : 스프링 시큐리티는 기본 제공 기능 외에도 사용자 정의 보안 로직을 추가할 수 있는 유연성을 제공
+- **인증(Authentication)과 인가(Authorization)**
+    - 인증
+
+        사용자의 신원을 검증하는 과정
+
+        ex) 사용자가 애플리케이션에 로그인할 때 입력한 아이디와 비밀번호가 올바른지 확인하는 작업
+
+        → 사용자가 누구인지 식별
+
+    - 인가
+
+        인증된 사용자가 애플리케이션의 특정 리소스에 접근할 수 있는 권한이 있는지를 확인하는 과정
+
+        ex) 관리자 계정은 관리자 페이지에 접근할 수 있지만 일반 사용자는 접근이 제한
+
+        → 리소스 접근 권한을 효과적으로 관리
+
+
+    스프링 시큐리티를 사용하면 이러한 인증 및 인가 작업을 효율적으로 처리 가능!
+
+    복잡한 인증과 권한 부여 로직을 직접 작성할 필요 없이 스프링 시큐리티가 제공하는 기능을 활용
+
+- **세션과 토큰**
+    - 세션 기반 인증
+        - 서버가 사용자마다 세션 ID를 발급하고 저장
+        - 사용자는 요청마다 세션 쿠키를 서버에 보냄
+        - 서버가 세션 ID로 사용자를 식별
+
+        **장점**
+
+        - 관리가 쉽고 오래 검증된 방식
+
+        **단점**
+
+        - 서버 메모리 사용 증가
+        - 서버 확장시 세션 동기화 이슈 발생
+    - 토큰 기반 인증 (대표적으로 JWT 사용)
+        - 로그인하면 서버가 **토큰 (JWT 등)** 을 발급
+        - 이후 요청마다 토큰을 헤더에 포함하여 보냄
+        - 서버는 토큰만 검증하고 별도 저장 불필요 (stateless)
+
+        **장점**
+
+        - 서버 부담 감소 (서버가 상태를 기억할 필요 없음)
+        - 서버 확장에 유리함
+
+        **단점**
+
+        - 토큰이 탈취되면 위험
+        - 토큰 만료/갱신 관리 필요
+- **액세스 토큰(Access Token)과 리프레시 토큰(Refresh Token)**
+    - Access Token
+        - 실제 API 요청시 사용
+        - 일반적으로 **유효기간이 짧음** (ex. 30분 ~ 1시간)
+        - 탈취 시 피해 최소화 목적
+    - Refresh Token
+        - Access Token이 만료될 때 새로운 Access Token 발급에 사용
+        - **서버에서만 안전하게 보관** (보통 DB 또는 Redis)
+        - 보안상 Refresh Token 유출 방지가 중요
+
+    ⇒ 보안성과 사용자 편의성의 균형 때문에 나눔
+
+    - Access Token이 짧게 유지되어 위험 최소화
+    - Refresh Token으로는 장기간 로그인 유지 가능 (자동 로그인 느낌)
+
+    ### 흐름
+
+    1. 회원가입
+        - 회원 DB에 ID, PW (암호화해서) 저장
+    2. 로그인 (인증)
+        - 사용자가 ID, PW 입력
+        - DB와 비교 → 일치 → 인증 성공
+    3. 로그인 성공 → 토큰 발급
+        - Access Token + Refresh Token 발급
+        - Access Token은 클라이언트가 API 요청시 항상 함께 보냄
+    4. 인가 과정
+        - 사용자가 요청할 때 Access Token에 있는 Role을 확인해 필요한 권한을 체크 (ex. ADMIN, USER 등)
+    5. Access Token 만료 → Refresh Token으로 재발급 시도

mission/chapter10/mission.md

@@ -0,0 +1,19 @@
+### 실습1 인증
+- 1번
+![실습1-1]("https://github.com/user-attachments/assets/fe0e3238-0c5c-4275-ac8a-b85eec387d3d")
+
+![실습1-2]("https://github.com/user-attachments/assets/b29cd948-e1ce-480e-9484-e93e60aac3db")
+
+![실습1-3]("https://github.com/user-attachments/assets/09d25a71-d402-4e58-a941-bb4cb46de435")
+
+![실습1-4]("https://github.com/user-attachments/assets/d0b327b4-8c9a-48e4-b1b3-af14e64c98e5")
+
+### 실습2 인증
+- 2번
+![실습2-1]("https://github.com/user-attachments/assets/90f8140e-1578-4fe3-bb4e-117976017f0")
+
+![실습2-2]("https://github.com/user-attachments/assets/e0691eaf-f1fe-44df-b41a-f0ded20cfba4")
+
+![실습2-3]("https://github.com/user-attachments/assets/c219a966-c2ac-4e41-aa7a-cee7ad015814")
+
+![실습2-4]("https://github.com/user-attachments/assets/cbac3b15-6724-4783-9a14-c6cba9c8c076")