week05 - Middleware, 유저 인증/인가, API 명세서 및 실습

[hyejungg]

🔥 알게된 점

1. Middleware
2. 유저 인증
3. API 명세서
4. API 실습

📚 배운 점

Middleware

• 요청과 응답의 중간
• 요청과 응답을 조작하여 기능을 추가하기도 하고, 나쁜 요청을 걸러내기도 함
• 요청 -> 미들웨어 -> 응답으로 동작
• ex. express-validator, 에러 핸들러, 라우더, 유저인증 등

유저 인증

무상태 프로토콜 (Stateless Protocol)

• 모든 요청이 상호 독립적
• 서버가 요청과 응답 사이에 어떤 데이터도 보존하지 않음
• 중간에 다른 요청이 다른 서버로 들어가도 문제 없음

인증 (Authentication)

• 사용자가 자신이 주장하는 바로 사용자가 맞는지 확인하는 절차
  • ex. 아이디와 비밀번호로 로그인

인가 (Authorization)

• 사용자가 특정 자원에 대하여 접근 권한이 있는지 확인하는 절차
  • ex. 개인정보, 로그인 해야만 열람 가능한 정보 등

인증 방법

1. Cookie

• 클라이언트 로컬에 저장하는 키-값이 들어있는 파일
• 일정 시간동안만 저장 가능
• 서버로부터 쿠키가 오면 웹 브라우저는 쿠키를 저장해두었다가 요청 시 브라우저가 자동으로 쿠키를 같이 보냄
  • 모바일 앱에서는 거의 사용 불가능
• 쿠키는 요청과 응답의 헤더에 저장

2. Session

• 웹 브라우저를 통해 웹 서버에 접속한 이후로 브라우저를 종료할 대가지 유지되는 상태
• 클라이언트는 발급받은 세션 아이디를 서버 메모리에 저장
• 서버가 재시작되면 세션 데이터도 사라짐. (메모리 리셋되니까)
• 넷플릭스, 인스타ㅡ램 처럼 하나의 사용자가 여러 로그인 정볼르 갖을 경우 유용
• 서버의 자원을 사용하므로, 속도가 느려질 수 있음

3. Token

(1) 인가 시도

(2) 확인된 사용자라면 액세스 토큰 제공

(3) 인증이 필요한 부분에 대한 로직 시 액세스 토큰 전송

(4) 받은 토큰을 검증 후 보호된 자원 제공

특징

• 보안성 : 정보가 담긴 데이터를 암호화
• self-contained : jwt 자체적으로 모든 정보를 포함
• 확장성 : 인증 저장소를 필요로 하지 않음

JWT (Json Web Token)

두 개체 사이에 JSON 객체를 사용하여 정보를 안전하게 전달

(1) Header : JWT 토큰 유형, 해시 알고리즘

(2) Payload : 클라이언트의 정보

(3) Signature : 서명 정보

jwt encode/decode 해보는 사이트

일반적으로 Token은 헤더의 Authorizaion 필드에 담김

Authorizaition:

<type> : 인증 타입. 전송 받은 인증 타입에 따라 토큰을 다르게 처리

Basic :

Bearer :

Digest

HOBA :

API 명세서

• 내부적으로 어떻게 구현되어 있는지 몰라도 명세서만 보고 사용 가능하도록 해야 함
  • 클라이언트에게 API 명세서를 제공 -> 우리가 만든 서버 API를 사용 가능
• 누가봐도 이해할 수 있도록 명확하고 직관적이어야 함
• swagger(ㅊㅊ), postman, notion, github wiki 등

API 명세서 구성 요소

1. API 이름 (ex. 영화 정보 조회)
2. HTTP Method (ex. GET)
3. Content-Type (ex. application/json)
4. Request Header, Body, Params, Query
5. Response Body (Success, Fail)