공식팀의 GitHub OAuth로 로그인하기 🔐

왜 깃허브 OAuth를 선택했을까? 🔐

공식팀에게는 회원가입에 대한 2가지 선택지가 있었다.

• 아이디 패스워드를 가입할 때 입력받아 직접 서버에서 관리하기
• 구글, 깃허브 등에서 제공하는 OAuth 활용하기

우린 그 중에서 깃허브 OAuth를 활용해서 회원가입을 하기로 선택하였다.
이유로는 크게 두 가지가 있다.

첫 번째로, 유저가 사용하기 편리하다이다

공식팀의 주요 타겟층으로 삼은 대상들은 우테코 크루들이였다.
우테코 크루들의 경우 전부가 GitHub를 사용하고 있었기 때문에 공식에 가입하기 위해서 Github를 새로 가입할 필요 없었다. 그저 기존에 가지고 있던 깃허브 아이디를 활용할 수 있었다.
또한, 공식을 위해서 아이디와 패스워드를 따로 생각해서 가입할 필요가 없이 깃허브 페이지에서 Approve버튼을 누르면 가입을 완료할 수 있었다.
매번 새로운 아이디와 패스워드를 만드는 건 정말 귀찮은 일이다

이러한 배경 덕분에 Github OAuth는 유저의 사용성을 높일 수 있는 좋은 선택지였다.

두 번째로, 보안이다.

유저에 대한 정보(=유저가 가입을 하면서 입력받은 유저의 개인적인 정보와 아이디, 패스워드) 특히 패스워드와 관련된 문제가 크다.
패스워드를 자체적으로 입력받고 DB에서 관리하게 된다면, 유저의 정보를 보호하기 위해서 패스워드 암호화가 필수적으로 필요로 된다. 그리고 해당 암호화를 관리하는데에 큰 리소스가 들게 된다 (예를 들어, 레인보우 어택이라던지 등의 여러 공격 상황에 대해 고려해야 한다) 그래서 공식팀은 해당 리소스를 기능 개발에 투자하기 위해서 깃허브 OAuth로 관리하기로 하였다.

깃허브 OAuth의 Flow 🔄

1. 공식 사이트에서 깃허브로 로그인하기 버튼을 누르기

공식에 접속한 유저는 로그인 버튼을 누르게 되면 위의 그림 처럼 깃허브로 로그인하기 페이지를 볼 수 있다.

프론트 단에서 깃허브로 로그인하기를 누르면 백엔드에게 어느 깃허브 URL로 리다이렉트 시켜야 하는지 물어보는 요청을 보낸다. 백엔드는 해당 요청을 받아 다시 프론트에게 url을 알려준다.

2. 프론트에서 깃허브 OAuth페이지로 보내주기

서버로 부터 리다이렉트 url이 성공적으로 전달받으면 지정된 깃허브 OAuth 페이지로 유저를 이동시킨다.

*지정된 깃허브의 URL 형식은 아래와 같다
github.com/login/oauth/authorize?clident_id={공식의 깃허브 아이디}&redirect_url={공식의 배포된 사이트 주소+ 깃허브에서 제공한 유저 코드}

-> 깃허브 URL이 고정되어 있음에도 서버에서 요청 하여 받아오는 과정을 한 번 더 거친 이유는? 🤔

: 깃허브의 client id는 새로운 레포지토리에 github oauth를 걸게 된다면 바뀔 수 있고 공식의 사이트 주소가 바꿀 수 있는 등의 상황이 있을 수 있다. 해당 상황들에 대응하기 위해서는 백엔드에게 매번 정보를 받아와야 안전할 수 있다.
덧 붙여 추후에 깃허브 뿐만 아니라 구글, 카카오 등의 OAuth를 사용하게 된다면 서버에서 리다이렉트 url을 다르게 보내주면 되기 때문에 프론트에서는 현재 url을 받아오는 비동기 통신을 재사용할 수 있게된다.

3. 유저의 Code를 깃허브로 부터 받기

유저가 Authorize버튼을 누르게 되면
깃허브는 공식팀이 사전에 깃허브 OAuth에 설정 해둔 배포된 사이트 주소에 유저의 아이디 정보를 붙여 리다이렉트를 시킨다.

프론트 단에서는 해당 리다이렉트를 감지하여 url에 붙여져 있는 유저 코드를 param을 통해서 가져온다.

4. 다시 백엔드로 로그인 요청을 보내기

앞서 param값으로 깃허브로 부터 제공받은 유저코드를 가지고 다시 백엔드에게 '이 유저의 로그인을 해줘'라는 로그인 요청을 보낸다.

공식의 경우 3 ~ 4 단계의 플로우를 처리하기 위해 프론트에서 로직과 로딩 화면만이 보여지는 페이지를 제작하였다.

5. 백엔드에서 깃허브에게 엑세스 토큰을 요청하기

백엔드는 프론트로 부터 제공받은 usercode를 가지고 다시 깃허브에게 유저의 엑세스 토큰을 발급해 달라는 요청을 보낸다.
깃허브는 해당 요청이 유효할 경우 응답값으로 추후 깃허브에게 요청할 때 사용할 수 있는 userAccessToken을 보내준다.

6. 깃허브에게 유저 정보를 요청하기

백엔드에서는 깃허브에게 제공받은 accessToken을 가지고 해당 유저의 정보를 요청한다. 깃허브에서 엑세스 토큰이 유효할 경우 유저 정보를 보내준다

7. DB에 유저정보 저장하기

백엔드는 앞서 깃허브로 부터 받은 유저 정보를 DB에 저장한다.
그리고 해당 유저 정보를 토대로 공식 사이트를 사용할 수 있는 권한이 담긴 accessToken을 자체적으로 만든다.
이렇게 만들어진 accessToken을 프론트에서 활용할 수 있도록 로그인 요청의 응답값으로 보내준다.

accessToken을 받은 프론트 측에서는 해당 값을 가지고 있으면서 추후의 비동기 요청 등에 활용한다

해당 플로우를 적용한 공식이 궁금하다면?
=> 공식 팀의 깃허브 레포 보러가기