"자정을 넘겨"
처음으로 자정을 넘겨 블로깅을 하게 되었습니다. 소셜 로그인 구현에 생각보다 시간이 오래 걸렸기 때문입니다.
어찌저찌 구현을 마치고 나니 아쉬운 점이 곳곳에 보입니다. 중복 체크나, 회원 데이터 반영 등에서 상당히 난해하게 구성된 점들이 보이기 때문입니다. 어떻게 금요일에 발표를 할 수 있는건지도 지금은 잘 모르겠습니다.
수정된 소셜 로그인 흐름도(카카오 기준)
어제의 블로깅에서 소셜 로그인 흐름도를 간략하게 정리했는데요. 클라이언트와 협업해나가면서 생각했던 것과 상당수가 바뀌게 되어 다시 흐름도를 정리해보려고 합니다.
카카오의 서버를 '카카오서버'로, 개발하는 웹앱의 서버를 '서버'로 표기하도록 하겠습니다.
➜ 클라이언트에서는 REST API 를 사용해 카카오서버에 인가 코드를 요청한다.
➜ 카카오서버는 사용자 인증 화면을 제공해 카카오에 등록된 유저인지를 판단하고, 확인을 마치면 인가 코드를 URI 주소에 담아 리다이렉트한다.
➜ 클라이언트는 URI 주소로 받은 인가 코드를 서버에 전달한다.
➜ 서버는 전달받은 인가 코드를 가지고 카카오서버에 토큰을 요청한다.
➜ 서버는 전달받은 토큰을 가지고 카카오서버에 사용자 정보를 요청한다.
➜ 서버는 카카오서버에서 전달받은 사용자 정보를 서버 내부의 사용자 정보와 비교한다. 일치하는 것이 없으면 유저 데이터를 생성한다.
➜ 서버는 자체적으로 발행하는 AccessToken 및 RefreshToken 생성해 클라이언트에 전달한다.
➜ 클라이언트는 전달받은 AccessToken(서버에서 발행)을 활용해 서버에 사용자 정보를 요청한다.
어제의 흐름도와 비교하면 많은 부분을 서버에서 해결하는 것으로 정리되었습니다. 그런 만큼 에러의 처리 등이 중요할텐데 이 점이 미비한 것 같아 걱정이 되네요.
인가 코드를 이용해 토큰을 발급받는 과정을 서버에서 진행할지 아니면 클라이언트에서 진행할지는 선택에 따라 달라질 수 있는 것 같습니다. 서버에서 진행하기로 한 것은 참고한 많은 자료들에서 그렇게 하고 있기 때문이었습니다.
다만 이렇게 하게 되면 카카오에서 발급받은 Refresh Token 도 바로 서버로 전달되게 됩니다. 개인적으로는 이렇게 진행되는 것이 좋은 방향은 아니라는 생각이 듭니다. 서버에서 Refresh Token 을 가지고 있는 것이 아니라 클라이언트가 관리하는 형태가 되어야 할 것 같거든요. 이 부분은 조금 더 공부가 필요한 듯 합니다.
추후에 시간을 내어 소셜 로그인(카카오)은 다시 한 번 전체적으로 정리해 블로깅을 해봐야겠습니다. 내일도 일정이 이어지는 만큼 오늘은 이 정도에서 정리하도록 하겠습니다.
