[WEEK00] 정글 5기 - 정글 입성 (3/18 ~ 3/21)

정글 크래프톤 0주차 과제!!!

- 3박 4일간의 간단한 미니 프로젝트

 

미니 프로젝트를 진행하면서 공부한 내용

SSR ( Server Side Rendering ) 이란?	- 웹 사이트에 접속하면 서버가 필요한 데이터를 가져와서 html 파일을 만드는 것 - SSR은 서버로부터 내용이 꽉 찬 html문서를 다운 받아와서 사용자는 화면을 빠르게 볼 수 있지만 이후에 js를 다운 받기 때문에 상호 작용은 js가 다운받아진 이후에 가능 장점 - 첫 로딩에 화면을 보는 시간이 빠르다 - SEO 문제 해결 단점 - 페이지 이동 시 모든 파일을 다시 받아오기에 UX가 좋지 않다. - 서버에 요청을 많이 하기 때문에 서버에 부담을 준다. - 사용자가 화면을 빠르게 확인할 수 있지만 js파일을 다운받는 시간차가 생길 수 있어 화면클릭 시 아무런 액션이 작동X
CSR ( Client Side Rendering ) 이란?	- 클라이언트 측에서 어플리케이션 렌더링이 이루어진다. - CSR은 서버로부터 빈문서를 다운로드 받은 후 js 파일을 가져와 사용자 입장에서는 화면 보기와 상호작용이 동시에 발생 장점 - 첫 로딩에 html과 js static 파일을 다 받으면 그 이후부터는 빠르게 렌더링이 이루어져 UX 상승 - 추가로 필요한 데이터만 요청하게 되어 서버에 요청을 하는 부담 감소 단점 - 사용자가 첫 화면을 보기 위해 기다리는 시간이 소요 - SEO(검색엔진 최적화) 문제 발생
SEO (Search Engine Optimization) 이란?	- 구글과 네이버 검색 엔진들이 서버에 등록된 웹 사이트를 돌아다니면서 웹 사이트의 html 문서를 분석해 검색엔진에 등록한다.
JWT 란?	- JSON Web Token - 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용하는 토큰
JWT 인증 방식을 쓰는 이유는?	- HTTP는 기본적으로 state-less를 지향한다. 장점 - 서버 확장성이 높으며 대량의 트래픽에 대처 가능 - 서버가 여러 대인 경우에도 특정 DB/서버에 의존하지 않아도 인증 가능 단점 - state-ful(세션) 방식보다 비교적 많은 양의 데이터가 반복적으로 전송되므로 네트워크 성능 저하가 발생될 수도 있다. - 데이터 노출로 인한 보안적인 문제 존재 (사실상 서명이 있기에 보완되는 단점)
state-less(무상태) 란?	- 서버-클라이언트 구조에서 서버가 클라이언트의 상태를 가지고 있지 않는 것
JWT(토큰 인증 방식) VS 세션	토큰 방식 - 토큰이 보안, 유저 데이터를 관리 - 서버 입장에서 가볍고 확장성이 좋은 방식 세션 - 서버가 보안, 유저 데이터를 관리 - 보안이 뚫리면 서버 개발자가 세션을 만료시켜 추가 피해 방지 - 서버 입장에서 무겁지만, 보안성이 좋은 방식
JWT는 어디에 저장할까?	- 로컬 스토리지와 세션 스토리지 같은 브라우저 저장소에 JWT를 저장한다면 스크립트 공격(XSS)에 취약하다 - 쿠키에 저장할 때 http-only를 사용한다면 HTTPS로만 쿠키가 전달되기 때문에 보안을 강화할 수 있다.
[ JWT 저장 위치 ]  HTTP쿠키(Cookie) VS HTTP 요청헤더(Authorization Header)	- 쿠키 저장 시 CSRF(Cross-Site Request Forgery) 공격으로부터 보호하기 위해 쿠키의 SameSite 속성을 설정하고, Secure 및 HttpOnly 속성으로 보안 - 헤더 방식은 쿠키를 사용하지 않는 stateless API나 SPA(Single Page Application) 에서 주로 사용된다. - CSRF 공격으로부터 보호할 필요가 없는 상황에 사용된다.
그럼 JWT의 보안을 높일 수 없을까? (Access Token & Refresh Token)	Access Token - 평소에 API 통신할 때 사용 Refresh Token - Access Toke이 만료되어 갱신될 때만 사용
Access Token & Refresh Token 동작원리	1. 로그인 성공 시, 서버는 클라이언트에게 Access Token과 Refresh Token을 동시에 발급하고, DB에 Refresh Token을 저장한다. 2. 클라이언트는 Access Token과 Refresh Token을 쿠키, 세션 혹은 웹스토리지에 저장하고 요청이 있을 때마다 이 둘을 헤더에 담아 보낸다. ------------ 토큰 만료 시 ------------ 3. 사용자가 이전과 동일하게 Access Token을 헤더에 실어 요청을 보낸다. 4. 서버는 Access Token이 만료됨을 확인하고 권한없음(401 Unauthorized) 신호를 응답한다. 5. 클라이언트는 Refresh Token과 Access Token을 함께 서버로 재요청한다. 6. 서버는 받은 Access Token의 조작여부, 요청 Refresh Token과 DB Refresh Token을 비교한다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급한다. 7. 서버는 새로운 Access Token을 헤더에 실어 다시 응답한다. 8. 만약 Refresh Token도 만료되었다면 서버는 동일하게 401 에러 코드를 보내고, 클라이언트는 재로그인해야한다.
쿠키/세션이란?
그럼 만약에 서버 분산시스템이 이루어져 있다면? ( 백엔드 서버가 2개라면? )	- 세션 공유 문제 발생! - 세션 동기화를 시킬 수 있는 방안을 고려
세션 동기화를 해결하는 방법	1. Sticky Session - 최초 요청을 받은 서버가 해당 클라이언트에 대한 요청을 모두 책임진다. - 최초에 어느 서버가 세션을 만들었는지 Cookie에 서버ID를 포함하거나 IP를 사용 - 가장 구현이 간단하고 응답속도도 가장 빠르지만 한 서버에 부하가 집중될 수 있고, 해당 서버가 다운되면 모든 세션 정보가 손실되는 단점이 존재. 2. Session Clustering - 세션 정보를 TCP Socket으로 서버끼리 공유하는 방법 - 사용자에게 빠른 응답을 주고 서버하나가 다운되도 세션이 손실되지 않는다는 장점이 있다. - 하지만 한 서버가 모든 서버를 알아야하기에 수많은 서버를 사용할 시 부적합하다. 3. Session Server - 최초 요청을 받은 서버가 세션 정보를 생성해서 외부 저장소에 저장한다. - 다른 서버가 클라이언트로부터 요청을 받으면 세션 정보를 외부로부터 가져와서 처리한다. - 응답 속도가 느리고 세션 서버가 죽으면 모든 서비스가 중단되는 리스크가 있다. - 서버를 스케일 아웃하기 편하고 마이크로서비스와 잘 어울린다.
Bootstrap 대신에 Tailwind의 장점은?	- 클래스 이름이 직관적이다.

 

회고

- 현업에서는 잘 사용하지 않는 방식인 SSR + JWT Token 이 요구사항이었다.

- 솔직히 덕분에, SSR도 물론이지만 JWT Token와 Session에 더 자세히 조사하고 알아가게 된 계기가 된 거 같다.