[SOPT] 5차 세미나 - Middleware, 유저 인증, API 명세서

공혁준·2022년 5월 14일
0

SOPT 활동

목록 보기
6/8
post-thumbnail

📌 이 글은 THE SOPT 30기 서버파트 5차 세미나에서 학습한 내용을 다룹니다.

Middleware

요청과 응답의 중간(middle, 미들)

미들웨어는 요청과 응답을 조작하여 기능을 추가하기도 하고, 나쁜 요청을 걸러내기도 함

Authentication

인증 Authentication

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

인가 Authorization

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

인증 방법

클라이언트 로컬에 저장되는 키와 값이 들어있는 작은 데이터 파일

  • 단순한 key-value 쌍 -> 클라이언트 로컬에 저장
  • 일정 시간동안 저장할 수 있음
  • 서버로부터 쿠키가 오면 웹 브라우저는 쿠키를 저장해두었다가 요청 시 브라우저가 자동으로 쿠키를 같이 보냄
  • 쿠키는 요청과 응답이 header에 저장됨
  • 모바일 앱에서는 거의 사용 불가능

Session

일정 시간 동안 같은 브라우저로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지하는 기술

  • 웹 브라우저를 통해 웹 서버에 접속한 이후로 브라우저를 종료할 때까지 유지되는 상태
  • 클라이언트는 발급받은 세션 ID를 서버 메모리에 저장
  • 서버가 재시작되면 (메모리 리셋), 세션 데이터가 사라짐
  • 넷플릭스 / 인스타그램처럼 하나의 사용자가 여러 로그인 정보를 가지는 경우 유용
  • 세션은 서버의 자원을 사용하기 때문에, 무분별하게 만들다보면 서버의 메모리가 감당할 수 없어질 수가 있고, 속도가 느려질 수 있음

Token

  • 보안성 : 정보가 담긴 데이터 (JSON 객체) 를 암호화
  • Self-Contained : JWT 자체적으로 모든 정보를 포함 (JWT 헤더, 전달할 데이터, 서명 데이터)
  • 확장성 : 인증 저장소 (ex. session DB) 필요하지 않음

JWT

Json Web Token

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

  • Header : JWT 토큰 유형 해시 알고리즘
  • Payload : 클라이언트 정보
  • Signature : 서명 정보

일반적으로 Token 은 HeaderAuthorization 필드에 담김

Authorization: [type][credentials]

Type: 인증 타입, 전송 받은 인증 타입에 따라 토큰을 다르게 처리한다.

대표적인 인증 타입

  • Basic: 사용자 아이디와 암호를 Base64로 인코딩한 값을 토큰으로 사용
  • Bearer: JWT 혹은 OAuth 인증
  • Digest: 서버에서 난수 데이터 문자열을 클라이언트에 보낸다. 클라이언트는 사용자 정보와 nonce를 포함하는 해시값을 사용하여 응답
  • HOBA: 전자 서명

API 명세서

  • API 명세서는 누가 봐도 이해할 수 있도록 명확, 직관적이어야함
  • 내부적으로 어떻게 구현되어 있는지 몰라도 사용 가능해야함
  • 클라이언트에게 API 명세서를 제공해야 우리가 만든 서버 API를 사용 가능!
  • 명세서를 작성할 수 있는 도구는 다양함 (ex. swagger, postman, notion, github wiki)
  • Notion, Github Wiki가 쉽게 작성 가능해서 처음할 때 추천합니다!

API 명세서 구성 요소

  • API 이름
  • HTTP Method
  • Content-Type
  • Request Header, Body, Params, Query
  • Response Body (Success, Fail)
profile
몰입을 즐기는 개발자입니다.

0개의 댓글