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

keyword/chapter09/keyword.md

@@ -0,0 +1,93 @@
+- 세션과 토큰의 차이는?
+
+  ### 세션 기반 로그인
+
+  사용자의 로그인 정보를 서버에 저장해두는 방식 → **Stateful**
+
+  사용자가 로그인하면 해당 정보를 서버 세션 저장소에 저장해두고 세션 저장소의 식별자를 클라이언트에게 전달하여 식별자를 통해서 사용자를 식별한다
+
+  로그아웃 시에는 세션 저장소에 있는 세션을 삭제한다
+
+  ### 토큰 기반 로그인
+
+  사용자의 정보를 서버가 저장하지 않고 토큰을 통해 추적 → **Stateless**
+
+  사용자가 로그인을 하면 서버는 해당 사용자의 정보를 담은 토큰을 발행해서 클라이언트에게 전달한다 클라이언트는 받은 토큰을 저장하여 매 요청 보낼 때마다 토큰을 같이 보낸다
+
+  로그아웃 시에는 토큰을 삭제하거나 블랙리스트로 관리하는 등의 조치 필요
+
+  ### 차이점
+
+    - 사이즈
+        - 세션은 세션ID만 실어보내면 되므로 네트워크 트래픽이 적음 하지만 토큰은 토큰의 발급시각, 만료시각, 토큰의 ID등 담겨있는 정보가 세션 ID에 비해 커서 네트워크 트래픽이 많이 필요
+    - 보안
+        - 세션은 모든 인증 정보가 서버에 있어서 보안에서 유리
+            - 해커가 세션 저장소의 식별자를 탈취하더라도 해당 세션을 무효하면 됨
+        - 토큰은 모든 인증 정보를 클라이언트가 가지고 있어서 탈취 당하면 해당 토큰이 만료되기 전까지는 할 수 있는게 없음
+            - 따라서 토큰 만료 기한을 짧게 두고 토큰 재발급을 위한 보조 토큰을 둬서 해결한
+        - 또한 토큰에서 Payload는 누구나 내용을 확인할 수 있으므로 들어갈 수 있는 정보에 한계가 있음
+    - 확장성
+        - 세션은 서버 여러 대를 사용할 때 세션 정보를 공유하는 추가 작업 필요
+        - 하지만 토큰은 필요 없음 → 확장성 높음
+    - 서버의 부담
+        - 세션은 서버가 세션 데이터를 직접 저장하고 관리해서 세션 데이터가 많아지면 부담 증가
+        - 하지만 토큰은 클라이언트가 인증 데이터를 가지고 있어서 서버의 부담이 준다
+
+  ### 실사용
+
+  보안이 중요하다면 세션,
+
+  서버를 여러 개 사용한다면 토큰이 유리
+
+- 엑세스 토큰과 리프레시 토큰이란?
+
+  ## Access Token
+
+  서버에 접근 할 수 있는 권한을 증명하는 역할
+  클라이언트는 API 요청 시 주로 HTTP Header의 Authorization 필드에 이 토큰을 담아 보냄
+
+  권한을 증명하는 역할을 하기 때문에 탈취가 된다면 해커가 탈취한 토큰을 통해서 마음대로 요청을 보낼 수 있음
+  따라서 주로 짧은 유효 기간을 가지고 Refresh Token과 함께 사용됨
+
+  ## Refresh Token
+
+  유효 기간이 짧은 access token이 만료 되었을 때 재발급 하기 위해서 필요한 토큰
+
+  긴 유효 기간을 가지고 있음
+
+  **[ 사용 예시 ]**
+    1. 처음 로그인을 할 때 서버는 클라이언트에게 엑세스 토큰과 리프레시 토큰을 전달한다
+    2. 서버는 리프레시 토큰만 저장하고 클라이언트는 둘 다 저장한 뒤에 요청이 있을 때마다 헤더에 담아서 보낸다
+    3. 이 때 만료된 엑세스 토큰이 온다면 리프레시 토큰을 저장한 리프레시 토큰과 비교한 뒤에 일치한다면 다시 엑세스 토큰을 발급해준다
+    4. 로그아웃하면 서버의 저장소에서 리프레시 토큰을 삭제하는 식으로 작동
+
+- OAuth 1.0과 OAuth 2.0의 차이는?
+
+  ### OAuth 1.0
+
+  초기 OAuth로 보안은 강했지만 구현이 복잡하다는 단점이 존재한다
+
+    - 매 요청마다 복잡한 서명(Signature) 생성해서 요청에 포함했어야 함
+    - Request Token, Access Token을 사용하고 만료 기한이 없음
+        - request token: 사용자가 아직 로그인/권한 허용을 하지 않은 상태에서 발급, 인증 전 권한 요청을 위해 쓰임
+    - HTTPS 없이도 비교적 안전하게 동작 가능
+    - 구현 난이도가 높고 개발 생산성이 떨어짐
+
+  ### OAuth 2.0
+
+  OAuth 1.0을 단순화한 버전
+
+    - 서명을 없애고 HTTPS 사용을 강제로 해서 통신 암호화를 맡김
+        - 개발자는 단순히 발급 받은 토큰을 HTTP 헤더(Bearer Token)에 담아서 보내기만 하면 됨
+    - Access Token과 Refresh Token의 개념이 공식적으로 도입되어 만료 기한을 가짐
+    - 다양한 인증 방식을 가짐
+    - 구조가 단순해져 구현과 유지보수가 쉬움
+    - 모바일 앱, SPA, 서버 애플리케이션 등 다양한 환경 지원
+
+  **OAuth 1.0**
+
+  → 요청 자체를 Signature로 보호
+
+  **OAuth 2.0**
+
+  → HTTPS 기반 Token 인증 방식 사용