Auth Server

Auth Server

DB - MySQL

• 우리의 프로젝트에서 상품 db와 채팅 db 등은 mongoDB를 사용합니다.
• 하지만 UserDB에 대해서는 MySQL을 사용하기로 결정했습니다.
• 회원의 정보를 관리하고 유지하는 서비스인 만큼 좀 더 정형화된 DB를 사용하고 싶어 RDB를 사용하기로 했고, 가장 대중적인 MySQL로 선택을 했습니다.

로그인 정보 - JWT

JWT

'Header'.'Payload'.'Signature'

Header

• 토큰 타입과 해싱 알고리즘

Payload

• 토큰의 정보
• 단위는 claim(key:value 쌍으로 이뤄짐)
• 클레임의 종류 : registered claim, public claim, private claim

registered claim

• 서비스에 필요한 정보가 아닌 토큰에 대한 정보를 담기 위해 이름이 이미 정해진 클레임들
• 필수가 아닌 optional

public claim

• JWT를 사용하는 사람들에 의해 마음대로 정의 될 수 있다.
• 충돌이 방지된 이름이 필요
• 따라서 클레임 이름을 URI 형식으로 지정

private claim

• client-server간 협의하에 사용되는 클레임

Signature

• 헤더의 인코딩값과, 정보의 인코딩값을 합친후 주어진 비밀키로 해쉬를 하여 생성

JWT를 선택한 이유

• 우리의 전반적인 서비스는 image resizing을 클라이언트에서 수행하는 등 서버의 부담을 줄이는 것에 초점을 맞추고 있습니다.
• 따라서 별도의 세션DB를 운영하지 않기 위해 JWT를 도입하기로 결정했습니다.

JWT 저장 위치

• 일반적으로 JWT는 쿠키 혹은 webStorage에 저장합니다. 다음과 같은 이유에서 우리는 Cookie에 저장하는 것으로 결정했습니다.

webStorage

• localStorage, sessionStorage로 나뉘며 차이는 세션 스토리지는 브라우저가 꺼지면 데이터가 삭제된다.
• 일반적으로 HTTP 요청시, Authorization 헤더에 Bearer 스키마로 함께 보낸다.
• javascript로 제어가 가능하므로 XSS공격에 취약할수도 있다.

Cookie

• 인증을 하면 서버에서 HTTP setCookie헤더를 통해 토큰을 보낸다.
• 브라우저는 이를 통해 쿠키를 생성하고 토큰을 저장
• 이후 해당 API 요청시 브라우저가 자동으로 이 쿠키를 실어서 보낸다.
• HTTP only, Secure 등의 옵션을 통해 보안 강화가 가능하다.
• 하지만 CSRF 공격에 취약할수도 있다.
  • 대응방안
  1. API에 대한 HTTP 요청을 특정 함수를 통해서만 이루어지도록 한다.
  • 이 함수를 통한 요청이 아닐 경우에는 인증을 거부(토큰에 특정 해쉬 값을 추가해서 발송하는 식 등)
  2. HTTP 헤더를 분석해서 막는 방법
  • HTTP 헤더에 있는 Referer 와 Origin 값을 통해서 엉뚱한 곳에서 요청이 날아 왔다면 이를 거부할 수 있다.

ref1 ref2 ref3 ref4 ref5