[9주차/유리] 워크북 제출합니다

keyword/chapter09/keyword.md

@@ -0,0 +1,144 @@
+- 세션과 토큰의 차이는?
+
+  ### 세션 (Session)
+
+    ```java
+    로그인 → 서버 DB에 세션 저장 → 클라이언트에 세션 ID 전달
+    요청마다 → 세션 ID로 서버 DB 조회해서 인증
+    로그아웃 → 서버 DB에서 세션 삭제 → 완전 무효화
+    ```
+
+    - 서버가 사용자 정보를 직접 관리
+    - 매 요청마다 DB 조회 필요 → 서버 부하 높음
+    - 강제 로그아웃 쉬움
+    - 주로 일반 웹사이트, 뱅킹에서 사용
+
+  ### 인증 방법
+
+    1. 클라이언트가 아이디/비밀번호로 로그인 요청
+    2. 서버가 DB에서 확인 후 세션 생성 → DB에 저장
+    3. 클라이언트에 세션 ID만 전달 (쿠키에 저장)
+    4. 이후 요청마다 세션 ID를 서버에 전송
+    5. 서버가 DB에서 세션 ID 조회 → 일치하면 인증 성공
+
+  ### **토큰 (JWT)**
+
+    ```java
+    로그인 → 토큰 생성 → 클라이언트에 전달 (서버는 저장 안 함)
+    요청마다 → 토큰 자체를 해석해서 인증 (DB 조회 없음)
+    로그아웃 → 클라이언트에서 토큰 삭제 (서버는 모름)
+    ```
+
+    - 클라이언트가 토큰을 들고 다님
+    - DB 조회 없음 → 서버 부하 낮음
+    - 강제 로그아웃 어려움 (만료 전까지 유효)
+    - 주로 모바일 앱, 여러 서비스 공유할 때 사용
+
+  ### 인증 방법
+
+    1. 클라이언트가 아이디/비밀번호로 로그인 요청
+    2. 서버가 DB에서 확인 후 토큰 생성 → 클라이언트에 전달
+    3. 서버는 아무것도 저장 안 함
+    4. 이후 요청마다 토큰을 서버에 전송
+    5. 서버가 토큰 자체를 해석 → 유효하면 인증 성공
+
+  ### 언제 어떤걸 써야 되는가?
+
+    - **세션 방식**은 즉각적인 사용자 상태 관리가 필요한 애플리케이션에 적합
+    - **JWT**는 확장성이 중요한 시스템에 적합
+
+  |  | 세션 | 토큰 |
+      | --- | --- | --- |
+  | 저장 위치 | 서버 DB | 클라이언트 |
+  | 인증 방법 | DB 조회 | 토큰 자체 해석 |
+  | 서버 부하 | 높음 | 낮음 |
+  | 로그아웃 | 완전 무효화 | 클라이언트에서만 삭제 |
+  | 강제 로그아웃 | 쉬움 | 어려움 |
+  | 사용처 | 일반 웹, 뱅킹 | 모바일 앱, SPA |
+- 엑세스 토큰과 리프레시 토큰이란?
+
+  ### 엑세스 토큰
+
+    - 엑세스 토큰은 사용자가 인증되었음을 나타내는 짧은 수명의 토큰
+    - 주로 API요청 시 사용되며 보통 몇 분에서 몇 시간의 유효 기간을 가짐
+    - 하나 또는 다수의 보호된 리소스에 대해 일정 기간 동안 접근할 수 있는 권한을 가지고 있으며, 범위와 기간의 속성을 가지고 있음
+
+  ### 리프레시 토큰
+
+    - 리프레시 토큰은 사용자가 다시 인증할 필요 없이 새로운 엑세스 토큰을 얻기 위해 사용되는 장기 자격 증명
+    - 사용자가 세션을 유지하고 더 나은 사용자 경험을 제공하는 데 사용됨
+    - 리프레시 토큰은 보통 몇 주에서 몇 달의 유효 기간을 가짐
+
+  ### 왜 둘 다 쓰는가?
+
+    - 엑세스 토큰은 유효기간을 아주 짧게 두어 특정 리소스를 얻기 위해 사용
+    - 리프레시 토큰은 유효기간을 상대적으로 길게 두어 엑세서 토큰을 갱신하기 위해 사용
+    - 생명주기가 긴 리프레시 토큰을 이용해 엑세스 토큰을 연장함으로써 사용자 경험을 향상 시킬 수 있음.
+
+  ### 전체 흐름
+
+    ```java
+    1. 로그인
+       → 액세스 토큰 + 리프레시 토큰 둘 다 발급
+
+    2. API 요청
+       → 액세스 토큰 사용
+
+    3. 액세스 토큰 만료
+       → 리프레시 토큰으로 새 액세스 토큰 재발급
+
+    4. 리프레시 토큰도 만료
+       → 다시 로그인
+    ```
+
+- OAuth 1.0과 OAuth 2.0의 차이는?
+
+  ### OAuth
+
+    - 구글, 페이스북, 트위터와 같은 다양한 플랫폼의 특정한 사용자 데이터에 접근하기 위해 제3자 클라이언트가 사용자의 접근 권한을 위임받을 수 있는 표준 프로토콜
+
+    ```jsx
+    "카카오로 로그인", "구글로 로그인" 이런 게 전부 OAuth
+    비밀번호를 직접 공유하지 않고 로그인할 수 있게 해주는 방식
+    ```
+
+  ### OAuth 1.0
+
+    - 최초 1.0 버전은 2006년 트위터와 Ma.gnolia가 주도적으로 개발
+    - **인증 방식**
+        - 권한 부여에 암호학적 서명을 사용
+        - 각 요청은 비밀 키와 해시 알고리즘을 사용하여 서명해야 하고, 소비자 키, 소비자 비밀, 요청 토큰, 접근 토큰을 사용하여 3단계 권한 부여를 지원
+    - **한계**
+        - OAuth 1.0은 웹 브라우저 환경에서의 인증과 권한 부여에 최적화된 프로토콜이었지만, 이러한 웹 브라우저에 최적화된 점이 제한
+        - 현재 여러 서비스 및 서버 구축에서는 서버 간 상호작용이 필수적으로 요구되는데, OAuth 1.0은 이를 지원하기 어려움
+    - **장점**
+        - 암호학적 서명으로 보안이 강력함
+        - HTTPS 없이도 안전하게 사용 가능
+    - **단점**
+        - 구현이 복잡함
+        - 웹 브라우저 환경에만 최적화
+        - 모바일, 서버 간 통신에 부적합
+
+  ### OAuth 2.0
+
+    - 1.0버전의 문제를 보완하고 기존 버전보다 조금 더 단순화한 OAuth 2.0 버전이 2012년에 등장
+    - 2.0 버전과 하위 버전은 호환되지 않음
+    - **인증 방식**
+        - 액세스 토큰과 함께 Bearer Token 권한 부여를 사용
+        - 토큰은 자원에 접근하기 위한 키 역할
+        - 앱을 위한 권한 부여 코드 부여 흐름으로 4단계 권한 부여를 지원하며 웹 앱, 모바일 앱 등 다양한 환경을 지원
+    - **장점**
+        - 구현이 단순하고 사용하기 쉬움
+        - 웹, 모바일, 서버 등 다양한 환경 지원
+        - 액세스 + 리프레시 토큰으로 보안 강화
+        - 현재 대부분의 서비스에서 표준으로 사용
+    - **단점**
+        - HTTPS 필수 (없으면 보안 취약)
+        - 1.0과 호환 안 됨
+    - **OAuth 2.0 흐름 예시 (카카오 로그인)**
+        1. 사용자가 "카카오로 로그인" 클릭
+        2. 카카오 로그인 페이지로 이동
+        3. 사용자가 카카오 아이디/비밀번호 입력
+        4. 카카오가 우리 서비스에 액세스 토큰 발급
+        5. 우리 서비스는 토큰으로 카카오 사용자 정보 조회
+        6. 로그인 완료