[TIL] 원티드 프리온보딩 FE 챌린지 day3 (주제: 세션기반 로그인 구현과 JWT와의 비교 및 인프라스트럭쳐) 후기 및 정리

📚Day3

우선 세션의 정의에 대해서 알아보는 시간을 가졌다. 실체가 있는 것과 실체가 없는 추상적인 개념(e.g. 질감)에 빗대어 이해하기 쉽게 설명해주신다. 
세션은 정확히 어떤 개념이다 라고 정의내리긴 어렵고 문맥상 "사용자의 로그인 이후 로그아웃 혹은 로그인 만료까지의 기간" 으로 통한다. 
정확히 우리가 말하는 "로그인 할 때, 세션을 활용해요." 에서 세션이란 정확히는 세션 방식 로그인을 말한다.
세션 방식 로그인이란 사용자 로그인이 유효한 시간 동안 서버에 세션 아이디를 기록해 두고 인증에 사용하는 방식을 말한다.  
보통 내가 알고 있던 세션 방식 로그인이란 서버에 세션아이디를 저장해두는 방식으로 진행되는데, 그래서 어떻게 하는 건지는 정확히 알 수 없었다. JWT처럼 엑세스 토큰이나 리프레쉬 토큰을 발급해서 클라이언트 단에서 직접 저장해준 적도 없고 이전 프로젝트에서도 JWT를 사용했기 때문에 그렇다.
 
서버가 세션 아이디를 기록하는 방법은 바로 "쿠키"를 이용하는 것이다. 여기서 말하는 쿠키란 HTTP 쿠키를 말한다. 

• HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각이다. 
• 이 데이터 조각을 브라우저에 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송한다.
• 쿠키는 두 요청이 동일한 브라우저에서 들어왔는지 아닌지를 판단할 때 주로 사용된다. (이를 이용하면 사용자의 로그인 상태를 유지할 수 있다.) ->⭐상태가 없는 http 프로토콜에서 상태 정보를 기억시켜주기 때문!

동작 방식은 이렇게 진행된다. 

1. 웹 브라우저가 서버에 웹 페이지를 요청한다.
2. 서버는 페이지와 함게 쿠키를 전송한다. 
   • 중요한 건 여기서 서버가 쿠키를 브라우저에 세팅한다. Response Headers -> Set-Cookies 를 보면 요상한 string들이 들어가 있는 것을 볼 수 있다(데이터 조각). 
   • Application -> Cookies에 가보면 저장된 쿠키를 확인할 수 있다.  
   • 브라우저가 쿠키를 서버에 전송하는 방식은 Request Headers 에 Cookie를 보면 알 수 있다. (세션방식을 사용하게 되면 프론트가 해야할 일이 줄어든다.) 서버가 뚝딱뚝딱 다 세팅해주는 느낌...
   • 실제로 Cookie는 프론트 개발자가 직접 넣어주는 값이 아니다. MDN의 Forbidden header name 목록을 보면 Cookie가 있는 것을 볼 수 있다. (목록에 있는 값들은 프로그래밍으로 수정하면 안되는 값들이다.)
3. 브라우저가 같은 서버의 다른 페이지(및 api)등을 요청한다. 

보안 문제에 대해서도 설명해주셨다.

쿠키 관련 정책 지정하기

SameSite 옵션 (옵션 값으로는 3개가 있다.)

• None :이건하면 안된다. 사랑의 쿠키나눔 행사 라고 강사님이 말씀해주셨는데 웃겨서 침흘렸다. 
  • none 은 말 그대로 너무 위험한 옵션값이기 때문에 secure 옵션을 같이 설정해줘야 한다. secure 설정 역시 서버(백엔드)에서 한다. secure 옵션이란 https 요청으로만 보낼 수 있다는 뜻이다. 
• Lax :중간쯤의 보안성을 나타낸다. e.g) get 요청의 경우는 권한이 없어도 어느정도 안전한 요청이기 때문에
• Strict :엄격하게 동일 사이트만 허용

+ 크롬의 경우는 2020년 2월부터 출시되는 Chrome 80부터, 선언된 SameSite 값이 없는 쿠키를 SameSite=Lax 쿠키로 취급한다. 

개발자는 새로운 쿠키 설정인 SameSite=None을 사용하여 크로스 사이트 액세스용 쿠키를 지정해야 합니다. SameSite=None 속성이 있으면 HTTPS 연결을 통해서만 크로스 사이트 쿠키에 액세스할 수 있도록 추가 Secure 속성을 사용해야 합니다. 이렇게 한다고 해서 크로스 사이트 액세스와 관련된 모든 위험이 완화되지는 않지만 네트워크 공격은 막을 수 있습니다.

-출처: 구글 검색 센터-

httpOnly 옵션

• httpOnly는 JS로 접근하지 못하게 하는 것이다. 서버에서 httpOnly야 라고 명시해주는 값이다. (이러면 프론트에서 쿠키값을 건들 수 없게 된다.) 만약 httpOnly가 걸려있으면 거기에 있는 값은 프론트에서 건들 수 없다. (서버가 세팅)

외에도 CORS 이슈에 대해서 설명해주셨다. 
CORS 이슈는 간단히 말하면 다른 집에서 온 인증서를 안받는 다는 것이다. 더 나아가서 너는 여기 접근도하지마!!하고 막을 수 있는 정책이다. 새롭게 알게 된 사실은 배포환경에 들어가게 되면 프론트에서 할 수 있는 일이 없다는 것이다. 하지만, 로컬 환경에서는 할 수 있는 일이 있는데, 로컬 환경에서 CORS 검증 해제 가능(스크립트 사용) 혹은 https로 로컬 환경을 띄우는 방법도 있지만 난이도가 있다고 한다. 결국 CORS 관련 이슈는 배포 전에 백엔드에서 처리해줘야 한다. 

📌 CORS 설정은 어떤 도메인에서 어떤 요청(자원)을 어떻게 처리할 것인가에 대한 정책이며 통신에만 영향을 미친다. 
쿠키는 별개이며 둘을 분리해야 한다. 쿠키가 httponly 등 옵션을 통해서 cors 설정과 비슷한 동작을 하도록 쿠키 정책을 설정할 수 있는 것이다. 

 

세션 로그인 구현 실습 

이번에도 실습을 진행했는데 서버와 클라이언트가 구현된 예제를 통해서 세션 로그인 로직을 구현하는 작업을 했다. 
CORS 무시 모드로 크롬을 실행해야 실습을 할 수 있으므로 환경 설정을 따로 해줘야 한다. 이 부분은 관련 extension이 따로 있다고 하는데 나는 수업에서 알려준 대로 윈도우 CMD에서 아래의 명령어로 CORS 무시 모드로 크롬을 실행했다. 

"C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-web-security --user-data-dir="C:\chrome"

위의 명령어에서 중요한 것은 각자의 로컬에서 chrome의 경로가 다르므로 경로를 확인 후 실행해야 한다. 
관련 자료로는 "Run Chrome browser without CORS" 사이트를 참고하면 된다.
 
또한, 쿠키를 통해서 세션 로그인을 구현해야하므로 프론트의 api요청 설정값으로 credential: 'include' 값을 설정해 줘야 한다. axios의 경우는 withCredential = true 로 설정해주면 된다. 이 설정을 해주어야 쿠키가 왔다갔다 할 수 있다. 
 

프로젝트 디렉토리 구조

외에도 프로젝트 디렉토리 구조에 대해서 알려주셨는데 결론적으로 말하자면 회사의 방침을 따르거나 같이 일하는 동료 혹은 내가 편할 수 있는 구조로 짜면 된다는 것이다. React 공식 문서에서도 이에 대한 의견은 따로 없다고 말하고 있다. 
예외적으로 assets 폴더에 들어가는 아셋 레벨의 프로퍼티들(이미지, 폰트, 동영상, json등..?)은 public 폴더에 둬야 한다.
-> 그래야 컴포넌트처럼 계속 불러오지 않고 브라우저가 캐시할 수 있다. 
 
Q. asset은 src 밑에 두지 않는 이유?

• build할 때, public은 그대로 그냥 들고가는데 src 아래에 있으면 모듈로 취급하여 해쉬값등이 붙는다. html이 아니라 js로 요청하기 때문에 캐싱이 안된다. 그렇기 때문에 src 아래에 두지 않는다. 이 부분은 webpack 번들러에 대해서 공부하면 된다고 한다. 

회고

이번 실습은 유일하게 수업 도중에 따라가지 못했는데, 초반엔 세팅에서 좀 버벅였고 예시대로 fetch가 아니라 axios를 사용했면서 예상치못하게 1번 문제에서 막혔다. 분명 post요청으로 제대로된 값을 보내는데 401 상태 코드가 떠서 당황했다.  그래서 우선은 개념적인 것만이라도 정리해두자 싶어서 메모장에 정리해놨다. 혹시라도 새로운 코드가 붙어있을까봐 해설할 때에도 집중하려고 노력..(했으나 내가 막힌 부분을 해결하고 싶어서 잘 안들어왔다.) 오늘은 어제 막힌 부분을 차분한 상태에서 작성하다보니 사실상 그리 큰 문제도 아니었다. 10분 만에 실습코드를 완성해서 뭔가 싶었다. 수업 너무 재밌당.. 마지막 날도 열심히 따라가야지