백엔드가 구글로그인을 붙이는건 생각보다 빠르게 되었는데 프론트엔드에서 붙일 때 좀 고생이 많았다. 가장 큰 문제는 우리가 비주류 방식을 선택한 것이다. 먼저 구글 로그인을 붙일 때 크게 2가지 방법으로 나뉘는데
프론트에서 구글에 로그인 요청하는 방식
백엔드에서 구글에 로그인 요청하는 방식
이렇게 이다.
프론트에서 먼저 구글에 로그인 요청 보내는 플로우는 다음과 같다.
그러면 프론트에서는 url에 담긴 인가코드를 추출해 백으로 인가코드를 전달한다.
전달받은 인가코드를 이용해 백엔드에서 구글서버로 유저정보를 요청한다.
구글이 유저정보를 전달해준다.
백엔드는 유저정보를 토대로 로그인 성공/실패 결과를 프론트에 전달해준다.(이때 서비스별 accessToken이 필요하다면 함께 담아서 전달한다)
이렇게하면 같은 서비스가 모바일로도 출시되었을 때 플로우를 바꿀 필요가 없어서 많이 사용되는 방법이라고 한다. 프론트가 비교적 귀찮은 방법이다. 관련되어서 구글링하면 방법이 많이 나오니 작성하진 않겠다.
우리는 백엔드가 다해줬다.😊 프론트가 이겼다기보단 로그인을 붙일 때 프론트가 많이 바빠서 백엔드쪽에서 할 수 있는 건 먼저 해둔 것이었음
우린 백엔드에서 대부분의 처리를 하는 방식을 선택했다. 잘 사용하는 방법은 아니기 때문에 참고부탁.
프론트에서 로그인 작업이 들어갈 당시엔 백엔드에서 이미 로그인 관련된 처리를 다 했기 때문에 로그인 요청 보내면 단순히 유저정보를 받으면 되겠지라고 생각했다.
그래서 처음 생각은 프론트에서 백엔드로 로그인 요청을 한다면 백엔드에서 알아서 처리하고 모아보기 페이지로 redirect 시켜주며 프론트가 로그인 정보를 받는다 였다.
하지만 여기서 문제가 발생하는데… 그럼 프론트는 모아보기페이지에서 항상 사용자 정보를 받는건가? 모아보기 페이지에서 사용자 정보를 어떻게 받아야하지? 라는 의문이 든 것. 모아보기페이지는 각 기능들을 요약한 곳으로 별도로 API를 요청하진 않는다.. 결국 로그인 정보를 받으려면 모아보기 페이지에서 다시 한번 사용자 정보를 받는 요청을 보낸 후 사용자 정보가 도착하면 로그인 되었다고 가정해야 하는 것이다.
이 방법의 가장 큰 문제는 모아보기페이지까지 가야 로그인 성공, 실패를 알 수 있다는 점이었다. 로그인이 실패했는데 로그인이 성공했을 때 보여주는 페이지로 이동해야만 알 수 있다? 뭔가 이상하다. 또한 모아보기 페이지에서 다수의 API 요청을 보내고 있는데 이 모든 요청은 사용자가 로그인되어야만 정상적으로 보내지기 때문에 인증실패 오류가 뜰 수 있음
그래서 어떻게 해야할까? 라고 생각한 와중에 내가 생각한 방법이 채택 되었다.
일단 우리는 백엔드가 만들어둔 flow를 전부 갈아엎을만큼 시간이 없었다. 최대한 만들어져있는 것을 살려야만 했다. 그래서
라는 나의 플로우가 가장 공수를 덜 들이고 현시점에서 할수 있는 우리의 최대라고 생각해서 채택된 것이다.
다만 백엔드에서 소셜로그인 url로 바로 redirect하면 구글쪽에서 cors 를 터트려서 프론트에서 로그인 요청에 대한 응답값으로 redirect시킬 url을 받아서 직접 해주는 방식이 추가되었다.
간단하게 말하면 아래와 같은 방법으로 프론트가 상대적으로 꿀빨 수 있다.
로그인 코드는 여기에서 보십쇼