10주차 - 나미/이나영 워크북 과제 제출

week10/keyword/keyword.md

@@ -0,0 +1,63 @@
+# WEEK 10 - 💧나미/이나영
+## Spring Security
+### 정의
+    인증, 권한 관리 그리고 데이터 보호 기능을 포함해 웹 개발 과정에서 필수적인 사용자 관리 기능을 구현하는데 도움을 주는 Spring의 프레임워크
+### 사용하는 이유
+    보안에 필요한 기능들을 제공하기 때문 -> 개발 작업 효율 UP!!!
+### 아키텍쳐
+    1. 사용자의 요청이 서버로 들어옴.
+    2. Authotication Filter 가 요청을 가로채고 AuthoticationManager로 요청을 위임함
+    3. Authotication Manager는 등록된 Authotication Provider를 조회하며 인증을 요구함
+    4. Authotication Provider가 실제 데이터를 조회하여 UserDetails 결과를 돌려줌
+    5. 결과는 SecurityContextHolder에 저장이 되어 저장된 유저정보를 Spring Controller에서 사용할 수 있게 됨
+
+## 인증(Authentication)과 인가(Authorization)
+||인증 (Authentication)|인가 (Authorization)|
+|-|-------------------|--------------------|
+|정의|개체(사용자 또는 시스템)의 신원(Identity)을 확인하는 과정|인증된 개체에게 특정 자원(Resource)이나 기능에 대한 접근 권한을 부여/거부하는 과정|
+|단계|보안 프로세스의 첫 번째 단계|인증 성공 후에 수행되는 후속 단계|
+|예시|아이디와 비밀번호를 입력하여 로그인하는 과정 (또는 OTP, 생체인식)|로그인 후, 관리자만 '사용자 삭제' 버튼을 볼 수 있거나, 일반 사용자는 자신의 프로필만 수정할 수 있도록 제한하는 것|
+|결과|신원 증명 (사용자가 맞는지 확인)|접근 허용/거부 (사용자가 권한이 있는지 확인)|
+## 세션과 토큰
+### 세션 Session
+    - 서버가 사용자의 상태를 저장하고 관리함 (상태 유지/Stateful)
+    --- 과정 ---
+    1. 사용자가 로그인에 성공하면, 서버는 서버 메모리에 사용자 정보를 저장하는 세션을 생성함
+    2. 서버는 이 세션을 식별할 수 있는 고유한 세션 ID를 생성함
+    3. 서버는 이 세션 ID를 클라이언트에 쿠키 형태로 전달함
+    4. 클라이언트는 이후 모든 요청마다 이 세션 ID가 담긴 쿠키를 서버로 전송함
+    5. 서버는 쿠키의 세션 ID를 통해 서버에 저장된 세션 정보를 찾아 사용자를 확인하고 인가함
+
+### 토큰 Token
+    - 서버가 사용자의 상태를 저장하지 않음 (상태 비저장/Stateless)
+    --- 과정 ---
+    1. 사용자가 로그인에 성공하면, 서버는 사용자 정보와 만료 시간이 담긴 인증 토큰을 생성하고 서명함
+    2. 서버는 이 토큰을 클라이언트에게 전달함
+    3. 클라이언트는 이 토큰을 로컬 저장소에 저장함
+    4. 클라이언트는 이후 모든 요청마다 HTTP 헤더에 토큰을 담아 서버로 전송함
+    5. 서버는 토큰을 받으면 시크릿키를 검증하여 토큰의 위변조 여부와 유효기간을 확인하고, 유효하면 토큰에 담긴 정보를 기반으로 인가 처리 
+       -> 서버는 별도의 DB 조회가 필요 없음 
+### 세션과 토큰 비교
+    - 웹 애플리케이션에서 사용자를 인증하고 상태를 유지하는 대표적인 두 가지 방식임
+    - 두 방식은 ^^서버가 사용자 상태를 관리하는 방식^^ 에서 근본적인 차이가 남!
+
+| 특징       |세션 기반 인증|토큰 기반 인증 (JWT)
+|----------|------------|-----------------
+| 상태 관리    |상태 유지 (Stateful)|상태 비저장 (Stateless)
+| 인증 정보 저장 위치|서버 (메모리, DB, Redis 등)|클라이언트 (Local Storage, Cookie 등)
+| 확장성      |서버 간 세션 공유 필요로 인해 어려움|서버 간 상태 공유 불필요로 우수함
+| 로그아웃/무효화 |서버에서 세션 삭제로 즉시 가능|만료 전까지는 즉시 무효화 어려움 (추가 로직 필요)
+| 사용 환경    |전통적인 웹 앱 (Monolithic)|SPA, 모바일 앱, Microservice, API 서버
+
+    최근에는 확장성과 분산 환경에 유리한 토큰 기반 인증(JWT) 방식이 모바일 웹, SPA, 마이크로서비스 아키텍처 등에서 널리 채택되고 있음
+## 액세스 토큰(Access Token)과 리프레시 토큰(Refresh Token)
+### 액세스 토큰 Access Token
+    - 역할: 실제 API에 접근할 때 사용되는 토큰, 사용자가 자원에 접근할 수 있는 권한을 가짐
+    - 유효기간: 매우 짧게 설정 (예: 30분/1시간)
+    - 저장 위치: 클라이언트의 메모리, 로컬 저장소 등에 저장됨
+    - 목표: 토큰이 탈취되더라도 짧은 시간 내에 만료되도록 하여 보안 위험을 최소화하는 것
+    -> 자주 사용: 매 요청 시 HTTP Authorization 헤더에 담겨 전송됨
+    -> 민감성: 짧은 유효 기간에도 불구하고, 이 토큰이 탈취되면 탈취 시점부터 만료 시점까지는 권한이 악용될 수 있어 가장 민간함
+
+### 리프레시 토큰 Refresh Token
+    - 역할: Access Token이 만료되었을 때, 서버에 새로운 Access Token 재발급을 요청하는 데 사용되는 토큰 

week10/mission/mission.md

@@ -0,0 +1,27 @@
+# WEEK 10 - 💧나미/이나영
+
+## session 방식 
+### 회원가입
+![img.png](sessionSignup.png)
+DB에 생성된 모습
+![img_1.png](sessionDB.png)
+### 로그인
+ROLE_ADMIN으로 변경 후 로그인하니, 스웨거로 리다이렉트 된 모습
+![img_2.png](sessionLogin.png)
+### 로그아웃
+주소에 logout 후 스웨거로 돌아가면 로그아웃 된 모습
+![img_3.png](sessionLogout.png)
+### 깃허브 브랜치 주소
+https://github.com/na311ng/umc9th-na311ng/tree/feat/SpringSecurity
+
+## token 방식
+### 회원가입
+![img_4.png](tokenSignup.png)
+![tokenDB.png](tokenDB.png)
+### 로그인
+![img_5.png](tokenLogin.png)
+token access 후 test 해보면 성공하는 모습
+![img_6.png](tokenAuth.png)
+![img_7.png](tokenTest.png)
+### 깃허브 브랜치 주소 
+https://github.com/na311ng/umc9th-na311ng/tree/feat/JWT