2023.07.05 TIL

오늘의 나는 무엇을 잘했을까?

다양한 프론트엔드 관련 지식에 대해 공부했다. 잡다한 지식들이지만 전혀 덜 중요하거나 잊어버릴만한 것들은 아니어서 꽤나 유용했고 프로젝트에 적용할 지식들이라 계속해서 복습해야겠다.

오늘의 나는 무엇을 배웠을까?

Miscellaneous

• 쿠키는 클라이언트에서만 삭제할 수 있는것이 아니다.

     <aside>
     💡 서버는 만료일이나, 또 다른 Set-Cookie 헤더를 사용해서 클라이언트에 저장된 쿠키를 삭제할 수 있습니다.
     
     </aside>
     

  접근권한 위임

  접근 권한 위임이란, 한 서비스가 다른 서비스에 있는 보호된 리소스에 대한 접근 권한을 위임하거나 받는 기능을 뜻한다. 예를 들어 코드잇 사이트에서 유저의 페이스북 프로필 사진을 받아오고 싶을 때 접근 권한 위임을 받으면 가능하다.
  

• 페이스북 사진을 가져오고 싶을 때 취할 수 있는 방법들

  • 개인이 페이스북에서 사진을 다운받아 직접 코드잇에 업로드한다. 하지만 이 방법은 번거롭고 자동화될 수 없다.
  • 코드잇에게 개인의 페이스북 아이디와 비밀번호를 알려줘서 코드잇이 개인 페이스북에 권한을 얻어 사진 가져오기를 자동화한다. 이 방법은 편리하긴 하나 악용될 여지가 많다.
  • 개발형 접근 권한 위임 표준(OAuth)을 사용한다.

OAuth

개인의 계정과 비밀번호를 제3자에게 알려주지 않으면서도 특정 사이트의 보호된 리소스에 접근할 수 있도록 처리해주는 절차

• 코드잇 사이트에서 오어스를 사용하여 유저의 구글 캘린더에 접근해서 스케줄을 연동하려고 하는 상황 예시
  

  • 이 상황에서 개입할 수 있는 주체들은 다음과 같다.
  • 구글 인가 서버에서 다양한 설정들이 필요하지만, 두 가지 핵심 설정들을 다음과 같다.
    • 구글 인가서버로부터 코드잇 고유의 클라이언트 ID와 클라이언트 시크릿이라는 값을 받는다. 코드잇을 구글 인가 서버에 회원가입 시킨다고 생각하면 된다. 그리고 이 코드잇 백엔드 서버에 이 값들을 저장해둔다.
    • 구글 인가서버는 스코프를 결정한다. 스코프란 인가 서버로부터 넘겨받으려는 권한의 범위이다. 예를 들어 스케줄 데이터에 대한 조회, 수정, 삭제, 생성에 대한 권한이라던지, 또는 유저가 가지는 모든 권한이라던지 하는 범위인 것이다. 이렇게 스코프를 정해둠으로써 구글 인가 서버는 스케줄 정보와 관련없는 정보들에 대한 요청을 거부할 수 있다.

• OAuth 워크플로우

  접근 권한을 특정 방식으로 주고 받기 위해서 각 주체들이 해야하는 작업들과 그 순서를 말한다.

  

  • authorization code: 유저 본인이 권한 위임을 원한다는 걸 확인시켜주는 데이터. 유저가 구글 계정 정보를 입력하면 구글 인가 서버가 코드잇 프론트엔드 서버에게 전달하는 데이터이다. 이 코드를 사용하지 않는 플로우도 있지만, authorization코드를 사용하는 플로우가 권장되는 이유는 보안상 안정성 때문이다. 누군가 authorization코드를 탈취하더라도 이 코드만으로는 인가 요청을 구글 인가 서버에 보낼 수 없다. client ID와 client secret이 있어야 하기 때문이다. 그런데 이 두 값은 프론트엔드가 아닌 백엔드 서버에 저장되므로 탈취위험이 낮다.

• OpenID Connect (OIDC)

  여러 사이트에서 접근에 대한 인가가 아닌, 인증을 하고 싶을 때 사용하는 프로토콜. 오어스에 인증까지 포함시킨 표준이라고 보면 된다. 한 사이트의 계정으로 여러 사이트에서 인증받기 위해 사용되는 것으로, 구글로 회원가입, 카카오로 회원가입 등의 소셜 로그인을 할 수 있게 하는 표준이다.

  OIDC를 사용하는 환경에서는 다음과 같이 4가지의 주체가 있다.

  

  • OIDC도 오어스의 일부와 같은 프로토콜이라서 많은 부분이 유사하다.
  • 먼저 프로바이더가 클라이언트 아이디와 시크릿을 발급해주고, 코드잇 백엔드 서버는 이 두 값을 저장한다.
  • 스코프를 정한다. 유저의 성과 이름, 프로필 사진, 생년월일 등 어떤 정보까지 제공할 지 범위를 정하는 것이다.
  • 워크플로우
  • id token은 access token과 달리 주 목적이 유저의 신원을 파악하기 위함이다.

• 멘토링

  • scss라고 부르지 말고 sass라고 부르는게 더 정확하다.
  • fork 방식 쓸거면 왜 썼는지 잘 알고있기를 바란다.
  • next-auth 쓰는거 좋은데, 너무 추상화되어있다 보니까 내부적 베이스 원리 지식들을 학습하고 아는 상태로 사용하면 좋을 것 같다.
  • 주소 입력 라이브러리는 다음 라이브러리 추천
  • 공통컴포넌트 잘 만들면 될듯.

오늘의 나는 어떤 어려움이 있었을까?

아무래도 많은 카테고리의 지식들을 하루에 정리하다 보니 머리가 조금 복잡해졌고 아직 다 체화가 덜 된 느낌을 받았다.

내일의 나는 무엇을 해야할까?

• 프로젝트 설계 시작하기