어느정도 화면 기획이 정해지고 디자인이 시안이 나온 후,
처음으로 본격적으로 개발한 기능 첫번째는 OAuth 연동이었다.
작년에 회사에서 소셜 로그인(OAuth)관련해서 세미나를 진행한 적이 있기 때문에, OAuth에 관한 개념이나 로직을 이해하는 데에서는 크게 문제가 없었다.
관건은 프론트엔드 / 백엔드 / OAuth Server 간의 통신 시퀀스 로직을 어떻게 설정하느냐였다.
사용할 OAuth 서비스
우리는 푸디지에 사용될 OAuth 서비스를 카카오, 네이버, 구글로 선정했다. 어느 애플리케이션에서든 소셜 로그인에서 이 세가지 서비스가 가장 많이 쓰인다는 것이 이유였다.
각 서비스의 개발자 문서를 열심히 뒤적거렸고, REST API 보다는 각 서비스가 제공하는 sdk를 사용하기로 했다.
그 이유는 우리가 개발할 푸디지는 PWA(Progressive Web Application)으로 개발하기로 했기 때문이다.
네이버나 카카오같은 경우 sdk를 사용하여 OAuth로그인을 구현하게 되면, 모바일 웹 환경의 사용자는 계정 정보 입력 없이 기기에 설치된 네이버 앱이나 카카오 앱으로 간편하게 로그인 할 수 있다. 이 때문에 sdk 사용이 PWA에 더 적합하다고 판단했다.
sdk로 구현 시, 모바일 환경에서는 아래와 같이 네이버 앱으로 간편하게 로그인 할 수 있다.
우리가 구현할 OAuth 로직
회사에서 깨찰님(백엔드)과 클라이언트, 우리 서버, Oauth 서버 간의 통신 로직을 어떻게 해야할지 의논을 많이 했다.
그래서 우리가 내린 결론은 권한부여 승인방식(Authorize Code Grant)으로 구현하되, Redirect URI를 프론트 url이 아닌 서버 url로 지정해 우리 서버가 인가코드, access token을 모두 받게 했다.
토이 프로젝트이지만 실제로 서비스 할 것을 생각해서 혹시 모를 보안 이슈를 생각해, 서버에서 모두 받게 하기로 결정한 것이다.
그리고 우리 서버 DB에서 가입한 사용자 데이터를 따로 저장하여 관리하기로 했다.
이를 바탕으로 시퀀스 다이어그램이 아래와 같이 그려졌다.
요약해 보면,
1. 클라이언트에서 Oauth서비스 sdk로 로그인 호출
2. OAuth 서버에서 로그인 화면 띄워줌
3. 사용자 로그인 성공 시, redirect URI(서버)로 인가 코드 전달
3. 서버가 받은 인가코드로 OAuth서버에 access token 요청
4. 요청 성공 시 우리 서버 DB와 비교하여 기존 가입 사용자인지 체크
5. 가입 여부에 따라 회원가입페이지 또는 로그인성공 페이지로 Redirect 시켜줌, 이때 같이 우리 서버가 발급한 자체 JWT를 전달.
이 순으로 진행되는 것으로 시퀀스를 짰다.
모든게 다 막힘없이 일사천리로 진행될 줄 알았는데 이 권한부여 승인방식이 우리의 발목을 잡게 될줄은 몰랐다....
골칫거리였던 문제점
하지만 개발하면서 뭐든지 생각대로 한큐에 잘 되는 법은 없다. 이번에도 마찬가지였다.
SDK를 사용한다는 것(PWA), OAuth 구현방식은 권한부여 승인방식(Authorize Code Grant)로 해야한다는 점이 문제였다.
왜냐하면, 카카오 로그인 SDK는 권한부여 승인방식으로 구현되어 있었지만, 네이버는 access token을 url로 전달하는 암묵적 승인방식(Implicit Grant)를 사용하고 있었기 때문이다...
이렇게 되면 서버가 각각의 서비스마다 다른 사용자 인증 로직을 짜줘야 하는데 그건 너무 비효율적이라고 생각했다. API URL을 이용하여 구현하는 방법도 있었지만, 이미 카카오 로그인 SDK를 써서 통일성을 유지하고 싶은 고집...이 있어 어떻게 하면 권한부여 승인 방식으로 네이버 로그인 SDK를 사용 할 수 있을까 고민을 하기 시작했다.
의외로 간단히 문제해결
해결방법이 없을까 계속 짱구를 굴리며 뚫어져라 콘솔 창에서 네이버 로그인 인스턴스를 살펴보았고..
prototype 객체에 있는 이 메소드를 보게 되었다.
보자마자 느낌이 팍! 왔다.
이게 바로 권한 요청 URL을 생성하는 메소드라는 것을.
그래서 바로 네이버 로그인 SDK script 내에서 저 함수명을 검색했다.
아니나 다를까, 아래와 같이 네이버 로그인 SDK 내부에서 암묵적 승인방식을 고정으로 승인 요청 URL을 생성한다는 것을 알게 되었다..!!
client ID와 CallbackUrl, isPopup 값 등은 개발자가 작성한 값을 받지만 'response_type=token' 즉, responseType을 'Token' 고정 값으로 URL을 생성한 것이다.
그래서 나는 script 파일 자체를 수정해버렸다.
response_type=code 이 한줄만 수정하고 네이버 로그인 SDK script js 파일을 프로젝트 디렉토리에 포함시켰다.
그 결과 우리 서버와 아주 잘 통신되었다 ^^
같이 일하는 서버 개발자 동료가 대단한 잔머리라며 칭찬을 아끼지 않았다. 🤟🏻
이렇게 네이버 로그인 구현은 의외로 간단히 해결하였다.
하지만 기쁨은 잠시... OAuth 구현 난이도 최고 강자인 구글이 남아있었다.
구글 로그인 구현에 대해 말하자면 너무 말이 길어 질것 같아서 다음 글에서 작성하려 한다.
힘내자 ㅎㅎ
'육첩방의 프로젝트 > Foodage' 카테고리의 다른 글
| [Foodage 개발 일지] 00 - 시작이 반이라고 하잖아요 (1) | 2024.03.11 |
|---|