현재 소셜 로그인 구조에 따른 책임 위치를 변경한다.

[compy-ryu]

지금 로그인 구조가 잘못된 구조는 아니라 생각하지만

장기적으로 보았을 때, OAuth를 관리하는 위치에 따라 소통비용이 훨씬 더 줄고
서로 개발 진행 상태에 따른 블로킹이 줄어 프로덕트 관점에서 이점을 가질 수 있을 것 같아보입니다.

현재 회고덕의 BE ↔️ FE, Github 로그인 구조

1. FE에서 Github의 Client Key, Callback URL을 환경변수로 가지고 있고, BE는 Secret Key를 가지고 있습니다.

2. 사용자의 로그인 요청 시, FE에서 직접 Client Key, Callback URL을 조합하여 Github Login 페이지로 보내주고 있습니다.

3. Github 로그인 성공 시 이동할 Callback URL은, FE의 페이지 URL을 가르키고 있어, 다시 FE로 넘어오게 됩니다.

4. FE는 callback url을 받을 페이지를 라우팅 해주고
   관련 로직과 OAuth 관련 예외 처리를 한 뒤, 다시 BE로 토큰을 파싱하여 보내주어야 합니다.

5. 이제 BE에서는 FE에서 보낸 토큰을 가지고, Github에 유저 프로필과 인증 요청을 진행합니다.

6. BE에서 유저 프로필을 성공적으로 가져 왔다면, FE는 access token을 받아옵니다만
   여기서 FE는 BE에서 유저 프로필을 가져오는 중 실패하는 상황에 대해 다시 한번 예외 처리를 진행하여야 합니다.

7. FE는 마"참"내! 유저 정보를 획득할 수 있습니다.

---

만약 아래와 같이 OAuth 인증 흐름을 담당할 위치를 한 곳으로 통합시키면 어떨까요?

1. BE에서 Github의 Client Key, Secret Key, Callback URL을 일괄적으로 관리합니다.

2. FE에서는 BE의 로그인 API로, FE로 다시 되돌아올 URL을 함께 담아 GET 요청을 보냅니다.
   (EX : api.ducks.kr/auth/login?callback=http%3A%2F%2Fducks.kr%2Flogin)
   (만약 Github 이외 소셜 로그인이 추가된다면 auth/naver/login과 같이 보낼 수 있을 것 같아유)

3. BE에서는 HTTP 상태 코드로 302 응답하여, 이동할 URL을
   BE에서 관리 중인 Client Key, Callback URL을 조합하여 Github 로그인 페이지로 이동하라고 직접 브라우저에게 알려줍니다.

4. Github 로그인에 성공하면, Callback URL은 BE 컨트롤러의 API를 바라보게 하여
   FE와 명세 협의 없이, BE에서 Github에서 응답 하는 값을 바로 가져올 수 있습니다.
   (인증 실패로 프로필을 가져오지 못하였을 시, FE의 Callback URL으로 Github에서 응답한 실패 사유만 Query String에 추가하여 Callback URL으로 이동시킵니다.)

5. BE는 Github가 제공 하여주는 응답 값을 바로 가져와, 사용자를 인증한 후 refresh token을 브라우저 쿠키에 등록하여준 뒤
   다시 302 응답과 함께, FE가 Query String을 통해 전달한 Callback URL으로 이동헙니다!

6. FE의 사용자 브라우저에는 refresh token이 등록되었으니,
   기존과 같이 access token을 획득하는 요청을 한번만 보내면 끝입니더!

---

이렇게 하였을 때 얻는 이점?

• BE에서 OAuth 관련 설정을 일괄적으로 관리할 수 있어, FE에게 설정을 요청하거나, 협의 과정을 생략할 수 있습니다.
• BE, FE 간 소통 비용 감소와 서로의 작업 진행 상황에 따른 블로킹이 줄어들 것 같습니다.
• 개발 초기 & 유지/보수 과정 중 BE와 FE가 서로 OAuth Callback URL을 바꾸어서 불편하였던 부분들을 모두 해결할 수 있어요.
• Github 로그인 이외에도, 네이버 / 카카오 / 구글 / 페이스북 / 애플과 같이 소셜 로그인이 계속해서 추가된다면....?

현재 구조에서의 문제, 예시 상황

- 명세 협의 & OAuth 세팅 정보, 설정 계정 공유를 진행하여야 하여야 함.
(API 여기로 요청하시고, FE에서는 Callback URL, ClientKey 설정하고, BE에서 SecretKey 이것으로 설정합시다!) 

- `FE` <=> `BE` 로그인 플로우가 제대로 작동되는지 테스트하기 불편하다.

- 여기에 CORS 이슈까지 겹친다면...?

요약 하자면

• FE에서 인증 중간에 개입하는 느낌이 있어, 이 부분에서 소통 비용이 증가하지 않을까요?
• FE가 인증 과정에 들어가게 된다면, 프로덕트 관점에서 봤을 때 관리 포인트만 서로 계속해서 누적될 것 같습니다.
• BE에서 OAuth 인증 흐름을 일괄적으로 관리하되, 소셜 로그인 인증 결과(성공/실패)에 대해서만 FE가 알게하는 것은 어떨까요?

[compy-ryu]

면접 기간인 관계상 수정 작업은 필수로 진행하지 않고, 일단 캠퍼스에서 협의만 진행해보아유!