현재 위코드에서 2차 프로젝트 진행중인데 소셜로그인을 구현하기로 했다.
사실 학부시절 프론트 개발을 배우는 수업에서 facebook 소셜 로그인을 구현한 적이 있어서 백엔드 과정을 진행하고있는 본인 입장에서는 '소셜로그인을 하는데 백엔드가 할게 있나?' 라는 의문이 들었다.

세션을 듣고 난 후에는 그 동안 맞지않던 퍼즐이 맞는듯한 짜릿함을 잠시 느꼇지만...
사실 처음에 든 의문이 70프로 정도는 맞다고 생각이 드는게 백엔드 입장에서는 딱히 설정할 것도 없어서 아주 틀린말은 아닌거 같다.

시작해보자!

주의: 해당 포스트는 '혼자'서 소셜로그인을 구현하는 것이 아닌, 명백하게 프론트엔드와 백엔드의 역할이 나누어 '백엔드입장'에서 처리해야할 내용에 대해 정리한 글입니다.

소셜 로그인의 전체적인 flow

생각대로 정리해서 다이어그램을 만들어 보긴했는데... 잘 모르겠다면 사과의 말을 남기고 시작하겠다.

프론트 엔드

1. 소셜 로그인 환경을 구축 및 세팅 한 뒤 해당하는 소셜로그인 플랫폼(네이버, 카카오, 구글 등)에 로그인을 해달라는 요청을 보낸다.
2. 로그인에 성공하면 소셜로그인 플랫폼에서 여러가지 잡다한(?) 내용과 함께 해당 사용자와 관련된 요청을 보낼 때 사용할 수 있는 'access_token'을 보내준다.
3. 해당 'access_token'을 다시 헤더에 담아 개발하고 있는(또는 개발된) 서비스측 의 서버로 보낸다.
4. 서버에서 로직을 처리한 후 서버자체에서 생성한 토큰 보내주고 해당 토큰을 localStorage 혹은 sessionStorage에 저장하여 사용한다.

백엔드

1. 위에 프론트엔드 3번 과정에서 받아온 토큰을 갖고 해당하는 플랫폼에 '해당 토큰의 사용자 정보를 주세요' 라고 요청을 보낸다.
2. 사용자 정보를 데이터 베이스에 저장하거나, 이미 저장이 되어있는 사용자면 해당 사용자의 데이터를 가져온다.
3. 우리 데이터베이스에서 가져온 사용자 데이터를 사용하여 JWT를 활용한 토큰을 생성한다.
4. 자체적으로 생성한 토큰을 프론트에게 응답으로 보내준다.

이게 정답일까?

현재 진행하고 있는 프로젝트에서는 위에 작성한 flow로 소셜로그인을 구현하긴 했는데, 사실 정답은 없는 것 같다. 맨 처음 말했던 거와 같이 백엔드 입장에서는 별로 할게 없는 것 같기도하고... 위에 flow에서 작성한 백엔드에서 소셜 플랫폼에 보내는 요청또한 프론트에서 보낸 후 받은 사용자 정보를 백에 넘겨주는 방식도 가능할 거 같다는 생각이 든다.

백에서 요청을 보내는 경우에는 서비스에서 이메일이 반드시 필요한경우에 해당 사용자가 플랫폼에 이메일을 등록하지 않은 경우에는 처리하기가 생각보다 복잡하다는 생각이 들기도하고, 차라리 백에서 이와같은 처리를 한 후 이메일이 없으면 이메일을 입력받는 것도 같이 구현한 뒤 좀 더 정리된 정보를 서버로 보내주는것이 백엔드 입장에서도 더 편할 거 같다.

무엇이 더 효율적인지, 혹은 더 합리적인지는 잘 모르겠어서 좀 더 찾아봐야겠다.

Django에서 구현예시

현재 구글, 네이버, 카카오 세개 모두 구현한 상태인데 일단 사진에는 구글만 올리겠다.
그 이유는, 사실 요청방식도 똑같고 api주소와 response로 받는 데이터 구조(?) 만 다를 뿐 전체적인 로직은 완전히 똑같기 때문이다.

위와 같은 이유로, 굳이 로그인하는 플랫폼 별로 뷰를 나누어야 할까라는 의문이 생기기도 한다.

2020-12-10 추가 - '굳이 뷰를 나눠야 하나?'에 대해

여러가지 이유가 있지만 가장 크게 와닿은 것은 OPEN API를 사용하는 경우에는 종종 변화가 생길 수도 있기 때문에 유지보수 측면에서 나누는 것이 유리하다고 한다.