[8주차/빈] 워크북 제출합니다

keyword/chapter08/keyword.md

@@ -0,0 +1,95 @@
+- Spring Security가 무엇인가?
+
+  ## Spring Security
+
+  인증, 인가, 외부의 공격으로부터 보호하는 프레임워크이다
+  spring security를 통하여 인증과 인가의 부분을 필터의 흐름을 따라서 처리하면서 더 쉽게 구현을 할 수 있다
+
+  Client → Filter → DispatcherServlet → Interceptor → Controller
+  (실제로 interceptor가 controller로 위임하는 건 아니고 거쳐서 가는 것임)
+
+  ### Security Filter Chain
+
+  ### SecurityContextPersistenceFilter
+
+    - **역할:** 이전에 로그인했던 사용자인지 기억해 내는 필터
+    - **동작 방식:** HTTP 요청은 기본적으로 이전 요청에서 로그인을 했더라도 다음 요청에서는 서버가 그 사용자가 누군지 알지 못한다. 이 필터는 클라이언트의 요청이 들어오면 가장 먼저 이전 세션(또는 저장소)을 확인하여 인증을 마친 사용자인지 파악하고, 저장된 인증 정보(SecurityContext)를 찾아내 현재 요청에 적용해 주는 역할을 한다.
+
+  ### UsernamePasswordAuthenticationFilter
+
+    - **역할:** 아이디와 비밀번호를 가로채서 로그인을 시도하는 필터
+    - **동작 방식:** Spring Security의 핵심 인증 흐름이 시작되는 출발점이다. 클라이언트에서 아이디와 비밀번호를 입력해 로그인 API를 호출하면, 이 필터가 해당 요청을 가장 먼저 가로챈다. 가로챈 정보로 임시 인증 객체(Authentication)를 생성한 뒤, 이를 AuthenticationManager에게 넘기며 실제 DB 정보와 대조해 진짜 회원인지 검증해 달라고 위임한다.
+
+  ### AnonymousAuthenticationFilter
+
+    - **역할:** 로그인하지 않은 방문자에게 임시 권한을 부여하는 필터
+    - **동작 방식:** 위에서부터 필터 체인을 쭉 거쳐 내려왔음에도 이 시점까지 인증 정보가 확인되지 않았다면, 서버는 로그인하지 않은 사용자에게 '명 사용자라는 임시 권한을 부여한다. 이를 통해 뒷단 로직들이 에러를 발생시키는 대신 "아직 로그인하지 않은 방문자구나"라고 안전하게 식별할 수 있다.
+
+  ### ExceptionTranslationFilter
+
+    - **역할:** 보안 관련 예외를 처리하고 안전한 응답을 내려주는 필터
+    - **동작 방식:** 바로 다음 필터나 뒷단의 컨트롤러에서 인증되지 않은 접근 또는 권한이 없는 접근 같은 보안 예외가 발생하면 이 필터가 낚아챈다. 에러로 인해 서버가 멈추거나 처리되지 않은 에러 메시지가 클라이언트에게 그대로 노출되는 것을 막고, 로그인 페이지로 리다이렉트하거나 규격화된 에러 응답을 반환하는 역할을 수행한다.
+
+  ### FilterSecurityInterceptor
+
+    - **역할:** 최종 목적지 도달 직전의 마지막 권한 검문소
+    - **동작 방식:** 필터 체인의 가장 마지막에 위치하며, 비즈니스 로직이 있는 컨트롤러로 요청이 넘어가기 직전의 최종 관문이다. 인가(Authorization)의 핵심 역할을 수행하며, "현재 사용자가 이 API를 호출할 권한이 있는지", "관리자 전용 API에 일반 사용자가 접근하려는 것은 아닌지"를 최종적으로 검사한다. 여기서 권한이 없다고 판단되어 예외를 발생시키면, 바로 앞단에 있던 ExceptionTranslationFilter가 이를 받아서 처리하게 된다.
+
+- 인증(Authentication)vs 인가(Authorization)
+
+  ### 인증 Authentication
+
+  어떠한 작업을 하고자 할 때 ‘로그인이 필요합니다’ 와 같은 문구가 뜬다면 인증이 필요한 상태
+  본인이 누구인지 확인하는 것
+
+    - 기능 : 자격 증명 확인
+    - 진행 방식 : 비밀번호, 생체 인식 등
+
+  ### 인가 **Authorization**
+
+  로그인을 하고 작업을 하려고 했으니 ‘권한이 없습니다’ 같은 문구가 뜬다면 인가가 필요한 상태
+  특정 리소스에 권한이 있는지 확인하는 것
+
+    - 기능 : 권한 허가/거부
+    - 진행 방식 :
+        - 역할 기반 제어 (RBAC) : 사용자에게 역할을 부여해서 역할에 따라 접근을 허용하거나 차단
+        - 토큰 정보 확인: JWT 같은 토큰 내부에 담긴 권한 데이터를 읽어들여 자격을 확인함
+        - 접근 제어 목록 (ACL): 특정 데이터나 API에 접근할 수 있는 사용자또는 그룹의 목록을 만들어두고 이를 대조함
+- Stateful vs Stateless
+
+  ## **Stateful (상태유지)**
+
+  클라이언트와 서버의 관계에서 서버가 클라이언트의 상태를 유지하는 것을 말한다
+  서버에서 클라이언트가 이전 단계에서 제공한 값을 저장하고 다음 단계에서도 저장한 상태이다
+
+  예시로 홈페이지에서 한 번 로그인을 하고 나서 페이지를 이동해도 로그인이 유지되는 상태를 말한다
+
+  이러한 정보들은 보통 브라우저의 쿠키나 서버의 세션 메모리에 저장되어 유지된다
+
+  ### 문제점
+
+    - 클라이언트가 이용하고 있는 서버가 멈추거나 여러 이유로 못 쓰게 되어 다른 서버로 사용해야 될 때 가지고 있는 정보들이 초기화 됨
+    - 한 서버가 최대 100명의 정보만 가지고 있을 능력이 된다면 그보다 많은 클라이언트가 몰린다면 100명 중 일부가 빠져야 다음 클라이언트가 처리가 된다
+        - 따라서 현업에서는 이러한 클라이언트의 상태 데이터를 따로 캐시 서버에 저장한다고 한다
+
+  ## **Stateless (무상태)**
+
+  이는 상태유지와는 반대로 서버가 클라이언트의 상태를 보존하지 않음을 말한다
+
+  여기서 서버는 단순히 요청에 응답을 보내는 역할만 수행하며 이때 통신에 필요한 모든 정보는 클라이언트가 가지고 있다가 한 번에 서버로 보낸다
+  → 서버의 부담이 줆, 서버가 바뀌어도 문제가 발생하지 않는다 (트래픽이 몰렸을 때 서버 확장에도 용이)
+
+  무상태의 예시로 HTTP 프로토콜이 있다
+
+  ### 문제점
+
+    - 클라이언트의 요청이 길어짐에 따라 네트워크 트래픽을 많이 씀
+
+  → 그냥 이벤트 정보 같은 요청이 필요 없는건 무상태가 좋지만 로그인에는 어쩔 수 없이 상태유지를 해야함
+
+  ### token
+
+  위처럼 로그인은 stateful을 해야하는데 이러면 서버의 부하가 생기는 것이 문제가 된다
+
+  따라서 stateless하면서 로그인 상태 유지를 위해 JWT 토큰을 사용한다
+  토큰은 클라이언트가 암호화된 로그인 정보들을 지니고 있다가 서버에 통신할때 넘겨줌으로써 내가 로그인 됬음을 인증하는 방식이다

mission/chapter08/mission.md

@@ -0,0 +1,4 @@
+![signup.png](signup.png)
+![signup2.png](signup2.png)
+
+![unauth.png](unauth.png)