로그인 관련 코드 리팩토링 및 사용자 전환 플로우 수정에 따른 로직 추가

[Mingyum-Kim]

PR의 목적이 무엇인가요?

• 로그인 코드가 기능을 추가하기 복잡한 형태로 되어있어 리팩토링하였습니다.
• 사용자 전환 플로우가 카카오 -> 구글, 애플에서 구글, 애플 -> 카카오로 변경됨에 따라 추가적인 로직을 구현하였습니다.

이슈 ID는 무엇인가요?

• 690

설명

구글, 애플로 로그인한 후 기존 카카오 인증 API로 데이터 이전 요청을 보냅니다. 서버에서는 카카오 통신 후 사용자의 identifier를 얻습니다. 그 다음 카카오 회원 데이터를 구글, 애플 회원 데이터로 갈아끼웁니다. 이 경우 같은 구글, 애플 회원이 두 행 존재하게 되므로 기존 구글, 애플 데이터는 삭제합니다.

이 과정을 통해 기존 카카오 회원을 구글, 애플 회원으로 이전하도록 합니다.

질문 혹은 공유 사항 (Optional)

• 로그인 API 엔드포인트 수정에 따라 애플 redirect_uri 도 수정하였습니다.
• 테스트 로그인 관련 컨트롤러를 별도의 클래스로 분리하였습니다.
• OauthClient는 미사용 중인 부분도 있으나 구현이 복잡한 만큼 로그인 기능이 정착된 후 제거하는 게 좋을 것 같아 남겨두었습니다.

<질문>

애플 로그인시 user가 전달되지 않고 (=최초 로그인이 아닌 경우) 회원 DB에도 없는 경우에 예외를 던지는 게 맞을까요? 지금 dev에서 한 번이라도 애플 로그인한 회원은 prod에서 애플 로그인 시 무조건 로그인이 실패하는데, 엣지 케이스를 어떻게 대응해야할 지 모르겠습니다. 이름이 없어도 대충 저장하고 따로 찾아가서 수정하는 게 좋을까요? 😅

[ay-eonii]

애플 로그인시 user가 전달되지 않고 (=최초 로그인이 아닌 경우) 회원 DB에도 없는 경우에 예외를 던지는 게 맞을까요? 지금 dev에서 한 번이라도 애플 로그인한 회원은 prod에서 애플 로그인 시 무조건 로그인이 실패하는데, 엣지 케이스를 어떻게 대응해야할 지 모르겠습니다. 이름이 없어도 대충 저장하고 따로 찾아가서 수정하는 게 좋을까요? 😅

개인적으로는 예외를 던지는 게 낫지 않나 생각해요. 테스트하느라 prod에서 로그인을 못하는 건 슬프지만(ㅠㅠ) 그건 모우다팀 + 우테코 소수 인원으로 한정될 것이고 데이터를 직접 조작할 수 있는 범위이지 않을까요? 실제 저희 서비스에서는 실명이 중요한 요소인만큼 대충 저장하기엔 위험요소가 있지 않나 싶네요!