diff --git a/keyword/chapter09/keyword.md b/keyword/chapter09/keyword.md new file mode 100644 index 0000000..c991a64 --- /dev/null +++ b/keyword/chapter09/keyword.md @@ -0,0 +1,143 @@ +- 세션과 토큰의 차이는? + + > 가장 핵심적인 차이는 “인증 정보를 서버에 저장하느냐, 아니면 클라이언트가 직접 들고 다니느냐”에 있다. + > + + **[세션 방식: 서버 중심]** + + 세션 방식은 사용자의 **로그인 상태 정보를 서버(메모리, DB, Redis 등)에 저장**하고 관리하는 방식이다. + + **<동작 방식>** + + 1. 사용자가 로그인하면 서버는 사용자의 세션 정보를 생성하고, 이를 구별할 수 있는 고유한 세션 ID를 발급한다. + 2. 서버는 이 세션 ID를 클라이언트에게 전송하며, 브라우저는 이를 보통 쿠키에 저장한다. + 3. 이후 클라이언트는 요청을 보낼 때마다 쿠키에 세션 ID를 담아 보낸다. + 4. 서버는 요청에 담긴 세션 ID가 서버의 세션 저장소에 있는지 확인하고 사용자를 인증한다. + + **<장 단점>** + + - **보안성/통제력**: 서버가 세션 정보를 직접 가지고 있어, 특정 사용자의 세션을 강제로 만료시키거나 제어하기 쉽다. + - ex) 중복 로그인 방지, 로그아웃 처리 + - **데이터 크기**: 클라이언트는 오직 짧은 세션ID만 주고 받아 네트워크 부하가 적다. + - **서버 확장성 문제:** 사용자가 많아질 수록 서버 메모리나 DB에 부담이 커지며, 서버를 여러 대 두는 분산 환경에서는 서버들이 데이터를 공유할 수 있도록 별도의 세션 서버를 구축해야한다. + + **[토큰 (Token, JWT) 방식: 클라이언트 중심]** + + ****토큰 방식은 인증에 **필요한 정보를 토큰 자체에 인코딩하여** 클라이언트가 직접 들고 있도록 하는 방식이다. + + **<동작 방식>** + + 1. 사용자가 로그인하면 서버는 사용자의 인증 정보, 권한, 만료 시간 등을 담은 **토큰**을 생성한다. 이때 **서버만 알고 있는 비밀키**로 **토큰을 서명(Digital Signature)한다**. + 2. 서버는 이 토큰을 클라이언트에게 전달한다. + 3. 클라이언트는 로컬 스토리지, 세션 스토리지, 또는 쿠키 등에 토큰을 저장해 둔다. + 4. 이후 요청을 보낼 때 HTTP 헤더(`Authorization: Bearer <토큰>`)에 이를 담아 보낸다. + 5. 서버는 토큰을 받으면 별도의 DB 조회 없이, **자신의 비밀키로 토큰의 서명이 유효한지만 검증**하고 바로 인증을 승인한다. + + **<장단점>** + + - **무상태성과 확장성**: 서버는 클라이언트 상태를 저장하지 않는다. 서버가 여러 대로 늘어나도 비밀키만 공유하고 있다면 어떤 서버에서도 토큰 검증이 가능하다. + - **MSA 친화적**: 여러 서비스가 분리되어 있을 때, 하나의 토큰으로 여러 서비스에서 공통으로 인증을 처리하기 쉽다. + - **제어의 어려움**: 토큰이 1번 발급되면 만료될 때까지 강제 회수나 무효화가 어렵다. 이를 보완하기 위해 만료 기간이 짧은 Access Token과 이를 재발급하는 Refresh Token을 함께 사용한다. + - **데이터의 크기**: 토큰에 많은 정보를 담을수록 토큰의 크기가 커져 요청마다 네트워크 트래픽을 더 많이 소모한다. + +- 엑세스 토큰과 리프레시 토큰이란? + + > JWT 기반 토큰 방식의 가장 큰 약점인 “한 번 발급된 토큰은 만료될 때까지 서버가 강제로 무효화하기 어렵다.”는 점을 해결하기 위한 보안 전략으로 토큰을 나눠 사용하는 **이중 토큰 인증방식**이다. + > + + **[엑세스 토큰 (Access Token)]** + + - 사용자가 로그인되어 있는 동안, 인증이 필요한 서버의 API를 호출할 때 헤더에 실어 보내는 **실제 인증 토큰**이다. + - 보통 보안을 위해 **유효기간을 매우 짧게** 설정한다. (30분 ~ 2시간) + - 유효 기간을 짧게 하여 해커가 토큰을 탈취하더라도 금방 사용할 수 없게 되어 피해를 최소화할 수 있다. + - 대신 사용자는 **수시로 토큰을 갱신**해야 한다. + + **[리프레시 토큰 (Refresh Token)]** + + - 엑세스 토큰이 만료되었을 때, 사용자가 다시 로그인 창을 보지 않고 **새로운 엑세스 토큰을 안전하게 재발급받기 위해** 사용하는 토큰 + - 유효기간을 상대적으로 길게 설정한다. (2주 ~ 한 달) + - 일반적인 API 요청에는 사용되지 않으며, **엑세스 토큰 재발급 API를 호출할 때만** 사용된다. + + **[전체 인증 흐름]** + + ```markdown + 1. 로그인 성공: 사용자가 로그인을 하면 서버는 액세스 토큰과 리프레시 토큰을 동시에 발급한다. + + 2. API 요청: 클라이언트는 평소에 액세스 토큰만 HTTP 헤더에 담아서 서버에 요청을 보낸다. 서버는 이를 검증하고 데이터를 준다. + + 3. 액세스 토큰 만료: 시간이 지나 액세스 토큰이 만료되면, 서버는 클라이언트에게 401 Unauthorized (또는 토큰 만료 에러 코드)를 반환한다. + + 4. 토큰 재발급 요청: 에러를 받은 클라이언트는 사용자가 모르게 보관하고 있던 리프레시 토큰을 담아 서버의 '토큰 재발급 API'로 요청을 보낸다. + + 5. 검증 및 재발급: 서버는 리프레시 토큰의 유효성을 검증한 뒤, 문제가 없다면 새로운 액세스 토큰을 만들어 클라이언트에게 다시 내려준다. + + 6. 요청 재시도: 클라이언트는 새로 발급받은 액세스 토큰을 저장하고, 실패했던 API 요청을 다시 보낸다. 사용자는 로그인 창을 다시 보지 않고 서비스를 계속 이용하게 된다. + ``` + + + +- OAuth 1.0과 OAuth 2.0의 차이는? + + > 외부 애플리케이션에 사용자의 비밀번호를 노출하지 않고 안전하게 권한을 위임하기 위해 만들어진 인증 표준 프로토콜이다. + > + + > OAuth 2.0은 1.0의 복잡한 암호화 계산 과정을 단순화하고, 다양한 환경에 맞춤형 인증 흐름을 제공하도록 재설계된 프로토콜이다. + > + + **[OAuth 1.0]** + + <암호화 방식과 디지털 서명> + + - 모든 API 요청마다 **디지털 서명을 생성**해서 호환해야 한다. + - HMAC-SHA1 등의 알고리즘을 사용해 요청 메시지를 복잡하게 암호화해야 했기에 클라이언트와 서버 모두 **구현이 까다롭다**. + - HTTP 환경에서도 보안이 유지된다. + + <토큰의 형태와 수명> + + - 한 번 발급받은 Access Token은 만료 기간이 없는 경우가 많아, 토큰이 탈취되면 수동으로 무효화하기 전까지 영구적인 위협 + + <인증 흐름의 분화> + + - 웹 브라우저 기반의 애플리케이션만을 염두에 두고 설계되었다. + - 따라서, 모바일 앱이나 단말기가 없는 환경에서는 적용하기 복잡하다. + + <확장성: 서버 역할의 분리> + + - 인증을 처리하는 서버와 실제 데이터를 제공하는 API 서버가 명확히 분리되지 않는 구조 + + **[OAuth 2.0]** + + <암호화 방식과 디지털 서명> + + - 복잡한 **디지털 서명 과정을 완전히 없앴다**. + - 통심 암호화 표준인 **HTTPS**에 보안을 전적으로 **위임**한다. + - 암호화 계산이 필요 없어져서 개발자들의 구현이 쉬워졌다. + + <토큰의 형태와 수명> + + - Access Token과 Refresh Token의 개념을 도입 + - Access Token의 수명을 짧게 제한하고, Refresh Token을 통해 안전하게 재발급받도록 설계하여 보안성 보완 + - 토큰 자체도 Bearer 토큰 형태를 사용한다. + + <인증 흐름의 분화> + + 시나리오에 맞는 4가지 이상의 권한 부여 방식을 제공 + + - Authorization Code Grant: 전통적인 백엔드가 있는 웹 사이트용 + - Implicit Grant: 백엔드가 없는 SPA(프론트 엔드 단독) 앱용 + - Resource Owner Password Credentials Grant: 신뢰할 수 있는 퍼스트파티 앱용 (ID, PW 직접 입력) + - Client Credentials Grant: 사용자 개입 없이 서버 대 서버로 통신용 + + <확장성: 서버 역할의 분리> + + - 인증 서버와 자원 서버의 역할이 개념적으로 명확히 분리되어 있다. + - 인증만 담당하는 서버를 따로 두고, 대규모 API 서버를 운영하는 MSA 등을 설계하기가 수월해졌다. \ No newline at end of file diff --git "a/mission/chapter09/images/\355\224\274\354\226\264\353\246\254\353\267\260_PR\353\246\254\353\267\260_\354\227\220\353\260\230_9\354\243\274\354\260\250.png" "b/mission/chapter09/images/\355\224\274\354\226\264\353\246\254\353\267\260_PR\353\246\254\353\267\260_\354\227\220\353\260\230_9\354\243\274\354\260\250.png" new file mode 100644 index 0000000..516e7b4 Binary files /dev/null and "b/mission/chapter09/images/\355\224\274\354\226\264\353\246\254\353\267\260_PR\353\246\254\353\267\260_\354\227\220\353\260\230_9\354\243\274\354\260\250.png" differ diff --git a/mission/chapter09/mission.md b/mission/chapter09/mission.md new file mode 100644 index 0000000..704324c --- /dev/null +++ b/mission/chapter09/mission.md @@ -0,0 +1,3 @@ +### 피어 리뷰 + +![에반_피어리뷰_제이의_워크북.png](./images/피어리뷰_PR리뷰_에반_9주차.png) \ No newline at end of file