항해99 | [실전프로젝트] passport를 사용한 OAuth 인증 기반 소셜로그인

docu·2023년 5월 15일

http-proxy-middleware passport

항해99

목록 보기

12/15

구현한 기능

passport를 사용한 OAuth 인증 기반 소셜로그인

구현 방법

/passport에 각 소셜로그인 서비스의 OAuth2 인증 전략을 설정
로그인 라우터 생성
콜백 라우터 생성
사용자 정보 저장
서버자체 토큰 발급

도전

express-session

express-session을 사용하지 않은 상태로 passport를 적용시켰더니 session을 사용해야한다는 에러 메시지가 났다.
마이페이지 api와 알림 기능 구현 전이여서 소셜로그인에 많이 할애할 시간이 없었고 찾아보니 express-session 개념이 생각보다 방대했다. passport도 처음 써보는데 express-session까지 처음 배우는 개념을 적용하면 에러를 처리할때 고려하지 못할 변수들이 많을 것 같았다. 제대로 이 개념을 이해하고 넘어가지 못한다면 과감히 생략하는게 낫다고 판단했다.
찾아보니 passport가 업데이트되면서 session이 적용돼야 가능했고 그 이전 버전을 이미 사용한 사람들이 같은 고민을 했던 것 같다. 자료를 참고로 express-session 적용은 하지 않았다.

http-proxy-middleware

[문제] 프론트와 백 도메인이 달라서 passport 전략 실행 후 콜백 라우터에서 서버자체토큰을 발급해서 쿠키값에 담아 프론트주소로 redirect하면 쿠키값이 안담기는 현상 발생

[해결방안]

쿼리스트링에 토큰값을 담아 프론트에 보낸다. 쿼리스트링으로 보내면 보안관련한 이슈가 있을 수 있지만 레디스에 토큰값을 임시저장하고 token_key만 쿼리스트링으로 보낸다면 극복가능하다 판단
http-proxy-middleware로 프록시를 설정해서 cors 정책을 우회한다
nginx에 프론트 서버를 배포한다

[2번 선택 이유]

- 쿼리스트링으로 토큰값을 보내면 보안상 안전하지 못할 수 있고 http-proxy-middleware를 사용하는것이 수월할 수 있다는 기술매니저님의 조언
- 프론트는 버셀에서 자동배포와 ssl 인증을 적용할 예정이었기 때문에 최대한 프론트는 계획한 예정대로 진행되게 하고 싶었음
- 프록시를 설정해서 cors 정책을 우회하면 프론트에서 추가적으로 쿼리스트링값을 처리해야할 필요가 없어서 작업량이 줄 것이라 생각

[2번 실행-http-proxy-middleware 적용]

controllers/user.controller.js 코드
app.js 코드

[추후 추가적으로 발생한 문제]

프록시 설정 후 /exhibition, /mypage, /artgram처럼 백엔드 api uri와 프론트엔드 주소가 겹칠 경우 새로고침 시 json값이 보이는 상황 발생

[해결]

백엔드 api uri 앞에 /api를 추가하여 겹치지 않게 설정함

아쉬운점

이용자 식별자 사용의 필요성
유저테스트를 할때는 그런 문제가 없었지만 팀에서 테스트를 하면서 여러계정으로 가입했는데 네이버로 이메일인증 회원가입을 한 사람이 다시 네이버 로그인을 시도했을때 오류가 나는 현상이 발생했다. 이 문제에 대한 실마리를 네이버 소셜로그인 앱 허가를 받으면서 얻을 수 있었는데
카카오 회원가입시에 id값을 사용했던 것처럼 이메일이 아닌 이용자식별자를 사용해서 가입을 했어야함을 깨달았다. 지금은 rds를 private으로 설정해두셔서 회원가입을 테스트해보기 어려운 상태여서 해결을 못했지만 다음번에 소셜로그인 구현시에는 더 완벽하게 기능 구현을 할 수 있을 것 같다.

완성본

회원가입이나 로그인은 무심코 지나갈 수 있는 부분이었는데 알아봐주시고 좋은 피드백들을 많이 주셔서 감사했다. 소셜로그인 기능을 구현하기까지 우여곡절도 마음고생도 많았는데 아쉬운 부분은 여전히 있지만 그래도 기능구현하기까지의 작은 목표들을 달성하는 순간순간들에는 정말 행복했던 것 같다.