[TIL] 원티드 프리온보딩 FE 챌린지 day4 (주제: 좀 더 깊이 알아보기 - OAuth 개념, 유저 역할 관리 등..)

마지막 강의는 여태 배웠던 큰 흐름에 대해서 복습하고 추가적으로 깊게 다룰 개념들에 대해서 강의했다.

📚복습

로그인이란?

- 사용자가 시스템에 접근하거나 동작을 수행하는 것을 제어하고 기록하기 위한 컴퓨터 보안 절차이다. 
 
로그인 과정은 사용자가 누구인가? 라는 '인증'부터 시작한다. (신원 식별 과정)
우리는 토큰 방식 로그인과 세션 방식 로그인에 대해서 배웠다.

• 토큰 방식: 엑세스 토큰이 유효한지 아닌지 확인 후 없으면 새 토큰 발급(리프레시 토큰 활용), 아니라면 토큰 유효성 검증
• 세션 방식: 토큰과 동일하나 프론트에서 추가적으로 조작할 일이 없음(간단)

세션이란?

- 사용자가 로그인하고 로그아웃할 때까지의 시간이다. (세션이 만료되었습니다. 를 생각해보세요)
 
위에서 신원을 식별했으면 권한을 제어해야 한다.
필요한 경우, 자기 자원에만 엑세스하도록 설정해줘야 한다. -> 실습했던 userProfile api 에서 403에러
백엔드에서 이미 해당 유저만 걸러서 보내주지만 프론트에서도 걸러줘야 한다. 

• 이전 실습에서는 백엔드에서 알아서 막았기 때문에 403을 주지만, 프론트에서도 할 수 있다. 
• 프론트에서 할 수 있기 때문에 백엔드에서 validation을 하지 않아도 되는 것은 아니다. 서버 valiation은 필수적이다. 
• 서버 validation이 없을 경우, postman과 같은 툴로 api를 찔러보면 중요 정보를 다 조회할 수 있기 때문이다. (서버와 프론트 둘 다 필터가 필요함)

서버에서는 그러면 어떤 작업(행동)을 하는 가?

1. (필요하다면) 본인의 자원에만 접근할 수 있도록 하기 
   • 유저 아이디를 바탕으로 유저의 다른 데이터를 볼 수 있는 서비스 e.g.)카톡, 인스타 등
2. 권한에 따라서 동작 제어하기 e.g) 깃허브 리포의 settings 버튼

위의 두 작업을 서버에서 진행하고 프론트가 권한 제어 작업을 시작한다. (결국 계속해서 양쪽에서의 validation 작업)

---

리프레시 토큰?

-리프레시 토큰은 엑세스 토큰을 재발급하는 용도로만 사용된다.
리프레시 토큰 로테이션 -> 토큰 순환 정책( 완벽한 보안 정책은 아니다. 딱, access token이 죽은 시점에 쿠키는 남아있는데 CSRF 공격이 들어오거나 살아있는 시점에서 탈취되어 사용되면,, 노답)
 
Q. 엑세스토큰의 payload의 변경이나 특정 값 변경으로 인해 기존에 클라이언트들이 사용하던 엑세스토큰을 전부 새 것으로 바꿔야한다면 어떤 식으로 처리하나? -> 프라이빗 키를 변경한다.

---

OAuth : open authorization

-허가된 다른 서비스를 통해 기존 서비스(google등)의 권한을 '위임'하는 것
 
* 배민(개별 서비스, 내 서비스), 구글(원본 서비스) 를 지칭한다.

• 원본(기존)서비스에서 로그인 -> 내 서비스에서 이용할 수 있도록 해줄겡 이런거 (대리 인증)
• 허가를 받는다는 의미는 시크릿 키를 받는다는 의미이다. 서비스의 시크릿키는 구글(원본 서비스)에 배민(내서비스) 등록할 때 알아서 생성된다.
• 사용자의 임시값은 로그인마다 달라진다.
• 구글의 로그인을 배민이 사용한 것, 배민은 유저가 인증해온 정보를 주고받기 통해 동작할 뿐이다.

그래서 프론트에서 OAutho에서 뭘하는가? 번거로운 작업은 링크를 보내는 것 뿐이다. open api를 쓸 때와 비슷하다. 
 
권한에 따라 OAuth 원본 서버(구글)의 유저 정보를 가져와 사용하거나 권한을 위임받는 동작을 할 수 있으며(e.g. Calendly- 캘린더에 일정 등록하는 서비스) 인증 자체만을 사용할 수 있다. 

---

여담: 싱글톤 패턴

- 데이터의 소스를 하나로 만들겠다는 의미

• 원래는 OOP(객체지향프로그래밍) 자바 등에서 쓴다. 
• 하나의 데이터가 여러 용도로 분화하여 사용된다. 
• 리덕스의 스토어도 코어 컨셉은 비슷하다.
• 우리가 실습한 예제에서 router.tsx 가 그 예시이다. 
• 프론트에서 디자인 패턴을 적용하기란 어렵지만 그 개념을 알고있으면 비슷하게 구현하여 사용할 수 있다. 

프론트에서 싱글톤 패턴이 필요한 이유? 

• 데이터의 소스(origin)이 달라지면 유지보수가 굉장히 빡세진다. api호출까지 겹치기라도 하면 개판이 된다..
• 서비스가 커질수록 중요하다. 결국 하나의 데이터가 하나의 맥락에서 관리되고 있는가가 핵심이다. 

외에도 모듈 번들러, 폴더 구조에 대해서 언급하셨다. 개인적으로 vite에 관심이 있는 터라 이 부분에 대해서 좀 더 다뤄주셨으면 했으나 주제를 벗어나기도 하고 수업 시간이 얼마 남지 않아 개인적으로 공부해야할 거 같다. 2023 03 20 기준, 리액트 베타 문서가 정식으로 공식화됐으며 이 과정에서 CRA가 권고되는 사항이 빠졌다. 해외 프론트 개발자 사이에서는 결국 vite가 답이다! CRA는 역사속으로 사라져야 한다 라는 쪽과 vite가 언급이 되긴 했으나 완벽히 CRA의 webpack을 대처하는 대체제는 아니라는 의견이 분분한 거 같은데.. 확실히 vite가 속도면에서는 빠르긴 하다. vite의 내부를 까보면 끔찍한 코드라는 둥 별의 별 의견이 있는데 나는 이런 것들을 파악할 만큼 숙련된 사람이 아니기 때문에 혼란스럽다. vite가 webpack에 비해 세팅하는 것이 심플한 것은 알겠으나 아무 배경 지식없이 사용했다가 이후에 발생할 호환성 문제나 오류에 대해서 우려가 된다. 그치만 사용했을 때 좋았으니 이 기회에 모듈 번들러에 대해서 공부해봐야지~

---

📌이번 실습 주제: 유저 권한에 따라 접근이 제어되는 웹 만들기
 

4일차 회고

이번 수업에서는 실습 위주의 수업이었어서 그런지 시간이 금방 흘러갔다. 3,4 회차에서는 서버 쪽도 클론 받아 실행하였는데 이 세팅과정에서 많은 분들이 버벅이게 됐다. 나도 조금 버벅였지만 서버 쪽을 아예 모르는 것도 아니고 사전 과제 시에 서버를 로컬에 세팅해서 작업해본 적이 있기 때문에 큰 무리없이 수행할 수 있었다. 이번에 크게 느낀 것은 TS를 사용해봐서 다행이라는 점..코드의 흐름을 따라갈 때 타입을 보면 이 로직에 대해서 더 쉽게 이해할 수 있어서 좋았다. 물론 좀 더 커다란 프로젝트를 다루게 되면 간단한 로직에서 더 방대한 코드를 작성해야겠지만 차후에 발생하는 오류를 미리 검증할 수 있다는 점이 매력적인 거 같다. 또한, 내 한계를 미리 정하고 이건 어려울거야 프론트는 아직 이정도는 몰라도 돼 같은 안일한 생각과 두려움은 내 성장에 걸림돌이 된다는 것을 알게됐다. 나는 내가 굉장히 더딘 사람이라고 항상 과소평가하곤 했는데 그건 그냥 어려움을 마주하기 싫어서했던 회피 행동이었다. 하다보니 뭐가 되긴 한다. 계속 해야하고 좋은 코드도 많이 접하고 자신감을 가지고 임해야 할 거 같다.