좀 더 깊이 알아보기 OAuth, … 그리고 이것저것

중간중간 실습 부분 기억이 날아가서 정리할 수 없었다.

로그인이란

• 보안 절차
  • 사용자가 시스템에 접근
  • 동작 수행 제어
  • 기록
• 토큰 기반 로그인: 토큰이 있는가? 토큰이 유효한가?
• 세션 기반 로그인: 세션이 유효한가?
• 권한에 따른 자원 접근 관리(사장님이 유저 전용 페이지 보지 못 함)
• 다른 유저의 자원 접근 관리(필요한 경우 다른 유저 정보 보지 못 함)
• 서버 밸리데이션은 필수
  • 모든 데이터를 받아온 뒤 프론트에서 필터링 등의 처리를 해서 보여주는 것 <- 절대 안 됨!
  • 민감 정보 등으로 문제가 있을 수 있다.

서버에서 하는 일

• 유저가 본인의 자원에만 접근할 수 있게 (마이페이지 같은..)
• 권한에 따라 동작 제어

그 다음 프론트에서 하는 일

• 권한에 따라 적절한 자원에 접근 (유저 권한이 없으면 로그인 페이지로 이동한다던가)

OAuth와 소셜 로그인

Open Authorization 허가된 다른 서비스(구글 같은!)에 권한 위임.

권한에 따라… 유저 정보 가져오기(유저네임이나 프로필 이미지 등) 권한 위임 받은 동작(캘린더에 일정 등록 등) 인증만 사용(로그인)

프론트에서 참 할 게 없음..

OAuth 작동 순서

0) 구글 등의 원본 서비스에 등록해 사용하겠다는 허락을 받는다.(시크릿 키를 받는다)
1) 유저가 내 서비스에 OAuth 인증 요청을 보낸다.
2) 내 서비스에서 유저에게 OAuth 로그인용 링크를 보낸다.
3) 원본 서비스에 인증 요청을 하면 유저에세 토큰을 전달한다.
4) 유저가 내 서비스에 토큰을 보내고 동작을 요청한다.
5) 내 서비스가 원본 서비스에 받은 토큰과 시크릿 키를 이용해 동작 요청한다.
6) 원본 서비스는 전달된 토큰과 시크릿 키를 확인해 동작을 승인한다.
7) 내 서비스는 유저에게 동작 수행을 및 응답을 한다.

프론트엔드와 싱글톤 패턴

싱글톤 디자인 패턴: 객체를 하나만 만들겠다…. 엄격한 의미에서 싱글톤 패턴은 아니지만 실습에서 구현한 것 중에 싱글톤 컨셉인 것이 있다?! => 라우터 객체~

라우터들의 정보(path, withAuth로그인 필요 여부 등)를 하나의 객체에 담아서 만들고, 이 라우터 객체를 여러군데에서 가져다 사용했다.

=> 하나의 데이터가 하나의 맥락에서 관리되고 있는가? (다른 곳에서 이미 바뀌어 버린 것이 아닌)신뢰할 수 있는 소스인가?

fetch로 받아오는 데이터인데 여기저기서 fetch 되거나, 상태관리로 치면 store가 두 개 이상 존재하면 문제가 생기기 때문에 하나로 관리.