[9주차/해피잭] 워크북 제출합니다.

keyword/chapter09/README.md

@@ -0,0 +1,115 @@
+- OAuth 2.0
+
+    ## OAuth 1.0과 다른 점은?
+
+    정리하면 다음과 같다.
+
+    - OAuth 1.0 → 복잡하지만 매우 안전함(서명 기반)
+    - OAuth 2.0 → 간단하고 널리 쓰임(토큰 기반), 대신 구현자가 보안을 잘 챙겨야 함
+
+    ### OAuth 1.0
+
+    - HMAC-SHA1 같은 디지털 서명(Signature)으로 요청마다 서명
+    - 요청이 중간에서 탈취돼도 사용할 수 없음 (timestamp + nonce)
+    - Client Secret을 노출하지 않아도 됨
+    - 모든 요청을 서명하므로 API 호출할 때마다 계산해야 해서 복잡
+
+    장점
+
+    - 고도의 보안성 (요청 조작 방지)
+    - HTTPS가 필수는 아니었음(그래도 안전)
+
+    단점
+
+    - 너무 복잡함 (Signature Base String 생성, 파라미터 정렬 등)
+    - 개발자 입장에서 구현이 귀찮아 거의 안 쓰게 됨
+
+    ### **OAuth 2.0**
+
+    - Access Token 기반
+    - HTTPS 사용을 전제로 설계됨
+    - 구조가 간단하고 모바일/웹/서버 모두 쉽게 적용 가능
+    - 구글, 페이스북, 카카오, 애플 등 거의 모든 곳이 OAuth2 기반
+
+    장점
+
+    - 구현 매우 쉬움
+    - 권한 부여 방식(Grant Type)이 다양함
+        - Authorization Code
+        - Implicit
+        - Client Credentials
+        - Resource Owner Password (Deprecated)
+
+    단점
+
+    - HTTPS를 반드시 사용해야 보안적 의미가 있음
+    - Access Token 탈취되면 모든 API 접근 가능 → 보안 위험
+    - 구현자가 제대로 안 만들면 보안 사고가 남
+
+    |  | OAuth 1.0 | OAuth 2.0 |
+    | --- | --- | --- |
+    | 인증 방식 | 디지털 서명 | Bearer Token |
+    | 보안 | 서명 기반(매우 강함) | HTTPS 기반 |
+    | 구현 난이도 | 매우 복잡 | 쉬움 |
+    | 모바일/SPA 지원 | 어려움 | 매우 쉬움 |
+    | 토큰 탈취 시 | 바로 못씀(재사용 불가) | 위험(바로 사용 가능) |
+    | 현재 사용률 | 거의 안씀(트위터 옛날 버전만 사용) | 거의 모든 기업이 사용 |
+- JWT
+
+    ## jwt
+
+    서버가 사용자를 인증했다는 ‘증명서’ 같은 토큰
+
+    - 로그인 성공 → 서버가 JWT 만들어서 클라이언트에게 줌
+    - 이후 요청할 때 JWT만 보내면 서버는 로그인 여부를 확인할 수 있음
+    - 서버는 세션처럼 상태를 저장하지 않아도 됨(= Stateless)
+
+    ## 왜 jwt 쓸까?
+
+    - 서버가 세션 저장 안해도 됨
+    - 요청마다 db 조회할 필요 없음 - 토큰 자체에 필요한 정보를 담고있기 때문(payload)
+    - 모바일에서 사용하기 좋음 > 문자열 하나만 저장하면 됨
+
+    ## 보안 이슈
+
+    - 시크릿 키를 매우 길고 어렵게 작성하고 안전하게 관리하기
+    - accessToken 탈취
+        - httpOnly cookie를 통해 훔치기 어렵게 만듦
+        - 유통기한 매우 짧게
+
+- Bearer Token
+
+    ## Bearer <token>
+
+    Bearer Token은 HTTP 기반 API에서 가장 널리 사용되는 인증 방식 중 하나로, 이 토큰을 소지(Bearer)한 사람에게 접근 권한을 부여한다는 의미를 가짐
+
+    클라이언트는 API 요청 시, 일반적으로 HTTP 요청의 **`Authorization` 헤더**를 통해 Bearer Token을 서버에 전송
+
+    **전송 형식:**
+
+    > Authorization: Bearer <token>
+    > 
+    - **`Bearer`:** 인증 스키마(Type)를 나타냄. 서버는 이 타입을 보고 해당 값이 Bearer Token임을 인지
+    - **`<token>`:** 실제 발급받은 토큰 문자열
+
+    ## 다른 종류의 권한 부여 방식
+
+    ### 1. api key
+
+    - 고유 비밀 키를 요청 쿼리 매개변수나 http 헤더에 포함시켜 전달
+    - 매우 간단하고, 주로 애플리케이션 자체를 식별하고 사용량을 제한하는데 사용됨 ex) openai key
+    - 단점: 키가 탈취되면 해당 키를 사용하는 모든 접근 권한이 넘어감. 사용자를 인증하는 용도로는 적합 X, 주로 서버-서버 통신이나 제한된 공용 api에 사용
+
+    ### 2. 기본 인증
+
+    - username:password를 base64로 인코딩하여 http authorization 헤더에 basic 접두사를 붙여 전송
+    - Http 표준에 정의된 가장 오래되고 단순한 방법
+    - base64 인코딩은 암호화가 아니어서 쉽게 디코딩 가능. 반드시 https와 함께 사용되어야 함
+
+    ### 3. 세션 기반 인증
+
+    - 로그인 성공하면 서버는 사용자 정보가 포함된 세션을 생성하고 서버 메모리나 DB에 저장
+    - 서버는 세션을 식별할 수 있는 id를 생성, 클라이언트에게 쿠키 형태로 전달
+    - 클라이언트는 요청 시마다 쿠키를 통해 세션 id를 서버에 전송, 서버는 이 id를 이용해 저장된 세션 정보를 찾아 사용자를 확인함
+    - 전통적 방식으로, 사용자 정보를 서버가 직접 관리하여 세션 무효화가 쉬움
+    - 서버가 상태를 유지해야하기 때문에 서버를 scale-out할 때 세션 공유 문제 발생해 확장성 떨어짐

keyword/chapter09/mission.md

@@ -0,0 +1,2 @@
+# 미션 수행 git 주소
+https://github.com/rbdus0715/UMC_NodeJS_Practice