[Day 61] 2022-0915: oAuth 깃허브 인증, Next.js

🐈오늘 공부한 것

✔️oAuth

oAuth란 흔히 네이버 로그인, 카카오 로그인, 깃허브 로그인 등 소셜 로그인을 가능하게 해주는 프로토콜이다. 토큰이 꼭 권한을 부여하는 쪽에서 생성하지 않아도 된다고 했는데, oAuth에서는 이미 사용자 정보를 가지고 있는 제 3의 서비스에서 인증 절차를 대신 해주고, 여기서 발급받은 권한 토큰(액세스 토큰)을 가지고 리소스 서버로 부터 정보를 요청하여 사용자에게 보여줄 수 있는 기술이다.

 

소셜 로그인은 유저 입장에서도, 개발자 입장에서도 편리하다. 이미 다른 곳에 있는 유저 정보를 활용해서 구현할 수 있기 때문에 이런 유저 정보 관리에 대한 신경을 덜 써도 되고, 유저 입장에서는 회원 가입이 간편화되기 때문에 편리하게 느낄 수 있다. 또 유저의 민감 정보가 직접 서비스에 노출되는 것이 아니고, 그 제 3의 서비스에 인증을 위한 허가또한 유저에게 구해야 하기 때문에 보안상으로도 유리한 점이 있다. 

 

oAuth 에서 기억해야하는 용어들은 아래와 같다. 

• Resource Owner : 사용자, 정보 제공자
• Client : Recource Owner 대신 보호 리소스에 액세스 하는 앱
• Local Server : Client 요청을 수락하고 응답하는 서버
• Resource Server : 사용자 정보 저장 서버
• Authorization Server : 인증 담당 서버. 액세스 토큰 발급 서버
• Authorization Grant : Client 가 액세스 토큰을 얻는 방법.
  • Authorization Code Grant Type
    • 사용자가 로그인을 했을 때 Auth 서버에서 code를 발급받아 로컬 서버가 이를 클라이언트로 부터 받은 뒤 다시 Auth 서버에게 액세스 토큰을 요청. 로컬 서버가 리소스를 클라이언트에게 전달.
  • Refresh Token Grant Type
    • 액세스 토큰 만료시 리프레시 토큰으로 새로운 액세스토큰 교환, 사용자와 추가 상호작용 없이 액세스 토큰을 갱신. 
• Authorization Code : 액세스 토큰 발급을 위한 Code
• 액세스 토큰
• 리프레시 토큰

여러가지 용어들이 있는데,  유저가 정보, Resorce의 주체이기 때문에 Resource Owner 가 된다. 클라이언트는 이 오너 대신에 유저 정보 즉 리소스에 액세스를 하는 앱인데, 먼저 이미 인증 정보를 가진 제 3의 서비스의 인증 담당 서버 - Auth 서버에 로그인 요청을 하게된다.

유저가 로그인을 승인하면 클라이언트 측으로부터 액세스 토큰을 발급받을 수 있는 Auth code 라는 것을 발급해준다. 클라이언트는 이 코드를 가지고 다시 인증 서버에다가 '액세스 토큰을 주쇼' 하고 요청을 한다.

성공적으로 액세스 토큰이 발급이 되면, 로컬 서버가 제 3 서비스의 리소스 서버에 액세스 토큰이 있으니 정보를 달라고 요청하고, 그 정보를 토대로 활용할 수 있게 된다. 

오늘 과제인 깃허브 소셜 로그인 구현 프로세스를 그림으로 그리면 아래와 같다. 

기본적인 개념과 플로우에 대한 설명은 여기까지...

사실 오늘 클라이언트 측 코드를 작성하면서 깃허브 요청 횟수로 인해 애를 먹어서 과제를 제대로 진행하기가 힘들었다. 주말에 카카오나 네이버 API 를 활용한 소셜 로그인을 구현해본 뒤 기록을 남겨야겠다. 

✔️Next.js

노마드 코더의 NextJS 시작하기 강의를 본 후 나름대로 정리한 내용.

 

동적 라우팅 Dynamic Routes

어떤 경로에 접근할 때 미리 지정된 파라미터를 사용해서 접근하는 방법도 있을 수 있겠지만, 입력에 따라 조금은 유연하게 접근할 수 있도록 하는 기술이 동적 라우팅이다. Next.js 에서는 이를 페이지의 하위 페이지 컴포넌트 이름에 대괄호를 작성하는 방식으로 활용하도록 하고 있다. 

 

Next.js 에서는 추가적으로, 여러개의 파라미터를 상황에 따라 가변적으로 받을 수 있는 기능을 제공하고 있다. 

Catch all routes

하위 페이지의 파일 명을 아래와 같이 spread 하게 되면, 이 페이지는 여러개의 파라미터를 통해서 접근할 수 있는 페이지가 된다. 기존에 [params].js 로 정의된 하위 페이지의 경우 페이지 라우팅을 할 때 route.push 같은 기능으로 쿼리를 추가로 넘겨주지 않는 이상 기본적으로 하나의 파라미터를 받게 되지만, 위와 같이 spread 된 이름을 가진 페이지에서는 / 슬래시로 이어서 들어오는 모든 파라미터에 route.query.prams 라는 프로퍼티로 접근할 수 있게 된다. 이런 방식을 코드로 구현하면 아래와 같다.

//index.js
const onClick = (id, title) => {
    router.push(`/movies/${title}/${id}`);
};

//[...params].js
export default function Detail() {
  const router = useRouter();
  const [title, id] = router.query.params || [];
  return (
    <div>
      <h4>{title}</h4>
    </div>
  );
}

이렇게 useRouter 를 통해 가져오는 파라미터들은 기본적으로 pre-rendering 이 된 html 파일을 받은 이후에 리액트를 실행시켜서 가져오는 값이기 때문에, 리액트가 실행되지 않은 상태에서 router 객체에 접근하려고 하면 undefined 에러가 발생할 수 있다. 따라서 단축평가로 undefined 일 경우에는 빈 배열이 오도록 한다.

 

만약 타이틀이라는 데이터를 CSR 방식으로 접근하는게 싫다면, getServerSideProps 함수를 사용해 SSR 방식으로 접근하여 이 값이 이미 담겨있는 pre-rendering html 파일을 생성할 수도 있다. 

export function getServerSideProps({params: {params}}) {
  return {
    props: {params},
  };
}

getServerSideProps 함수는 context 라는 인자를 받아올 수 있는데, 이 인자에 포함된 params 값이 클라이언트에서 dynamic route 를 사용할 때의 바로 그 파라미터의 값이 된다. 위와 같이 구조분해할당하여 props로 리턴해주면, app 컴포넌트를 통해 렌더링할 컴포넌트에 이를 전달해주어서 페이지를 만들 수 있다. 

 

이 동적 라우팅이라는 개념이 네트워크에서 나오는 동적 라우팅과는 약간 다른 것 같다. 나름대로 이해한 것을 정리했는데 어째서 이 코드가 동작하는지 명쾌하게 설명하는게 좀 어렵게 느껴진다. 라우팅에 대해서 좀 더 공부해야겠다. 

🐈더 공부할 것

1. 알고리즘 문제 풀기

2. Next.js : rewrite, Dynamic route

3. 비동기 API 호출 복습, 소셜 로그인 구현

🐈오늘의 느낀 점

1. 오늘 과제를 하면서 의외로 막혔던 부분은 API 를 비동기적으로 호출하는 부분이었다. axios 를 처음 사용해봐서 그런 것일 수도 있겠지만 post 요청을 보낼 때 보내주는 payload 작성 등 개념이 명확하지 않으니 응용도 잘 되지 않는 것이 느껴졌다. 인증 구현 연습을 하면서 API 호출 부분도 복습하면 좋을 것 같다.

 

2. Next.js 시작하기 강의를 마무리 했는데, 속성 코스이다 보니까 빠르게 흘러간 부분도 있고 왜 이렇게 동작하는지 명확하지 않은 부분이 많다. 특히 라우팅,, 왜 동적으로 변하는 url이 필요한 것인지 잘 모르겠다. 

 

3. 내일 부터는 솔로 프로젝트로 직접 웹앱을 만드는 연습을 한다. 아마 리액트와 리덕스 툴킷을 사용할 것 같다. 근데 사실 마음같아서는 다시 자바스크립트부터 돌아가서 한땀 한땀 만들어 보고 싶기도 하다. ㅋㅋ