`POST v1/oauth/{provider}` 소셜 로그인 구현

[subeenpark-io]

1. 기본적인 흐름

• POST /v1/ouath/{provider}로 요청 시 해당하는 이메일의 유저가 이미 존재하면 로그인 처리, 존재하지 않을 경우 유저 생성 후 로그인 처리

  {
  "access_token" : "ya29.a0ARrdaM8sHAD8ASHlI3-nrZaL3_DPMhw_rD1eu2cY18Umv_yd3NQF14gK-4HSKxlEHkrZSxHQfTOswZvxIefwuBNxuc43iAGG5W4tgRhSyLf0obesdDTiE89l_K-fiQpH70h1YBlEd0bZJHbC9n60l_hjzBfn4_QO48TK"
  }

2. 실제 구현

소셜 로그인 구현의 경우 spring-security의 도움을 일부 받았으나, spring-security에서 기본으로 제공하는 oauthLogin 구성의 경우 웹을 리다이렉트 시켜 authorization code를 받는 방식으로 모바일 친화적이지 않은 면이 있습니다. 따라서 이번 구현에서는 리소스 오너가 access_token을 보내준다는 가정 하게 API를 구현했습니다. 아래는 PR을 읽는 데 있어 참고하면 좋은 사항입니다.

-ReactiveClientRegistrationRepository

• AWS Secrets Manager를 통해 아래와 같이 applications.yml에 새로 발급한 client-id와 client-secret가 채워집니다. Spring Boot 2.x 에서는 아래의 정보들을 바탕으로 ReactiveOAuth2ClientAutoConfiguration이 동작하고, ClientRegistration 정보가 들어있는 ReactiveClientRegistrationRepository를 @Bean으로 자동으로 등록합니다. 이번 구현에서는 ReactiveClientRegistrationRepository의 ClientRegistration을 기본으로 리소스 서버와 소통합니다.

  security:
    oauth2:
      client:
        registration:
          google:
            client-id:
            client-secret:

• 유저가 전송한 access_token을 기반으로 provider와 소통해 유저의 정보를 받아오는 과정은 {Provider}UserService}에 구현되어 있습니다. OAuth2UserServiceFactory가 SocialProvider를 기반으로 실제 구현체 Service를 돌려주는 방식입니다. 아래와 같이 Mono를 돌려주는 형태입니다.

  return clientRegistration
          .flatMap { clientRegistration ->
              webClient
                  .get()
                  .uri(clientRegistration.providerDetails.userInfoEndpoint.uri)
                  .headers {
                      it.setBearerAuth(accessToken)
                  }
                  .retrieve().bodyToMono<GoogleOAuth2UserResponse>()
          }

• 저희 프로젝트의 전반은 Coroutine 기반으로 구현되어 있는 데 반해 webClient는 Reactor 방식으로 동작합니다. suspend function과 Mono/Flux의 혼용은 이 레포를 참고했습니다.

3. 기타

3.1 아직 처리되지 않은 부분

• 로컬 유저와 동일한 이메일의 계정으로 소셜 로그인을 하려고 할 때
• registeredClient 이외의 provider에 대한 endpoint에 접근했을 때
• account_user.password를 어떻게 할건지?
• 이외의 자세한 ExceptionHandling

[subeenpark-io]

요청 시 해당하는 이메일의 유저가 이미 존재하면 로그인 처리, 존재하지 않을 경우 유저 생성 후 로그인 처리라는 flow에 문제점이 있을 것 같습니다. 가입되지 않은 유저가 로그인을 누르면 클라이언트는 로그인 API로 요청을 보낼 텐데, 원하지 않는 가입이 생길 수도 있을 것 같습니다. 반대로 전에 회원가입을 했다는 사실을 까먹고 회원가입을 눌렀을 때도 가입이 실제로 되는 것이 아닌 로그인 flow만 이루어질 수 있다는 점이 불안합니다. 차라리 로컬 로그인처럼 로그인과 회원가입 API를 분리하면 좋을 것 같습니다. 또, 이외에도 ktlint 에러 등등 수정 부탁드립니다.

@chosanglyul 이 부분은 이해가 되지 않는데요, 소셜 로그인의 장점 자체가 신원을 보장해주는 third party IdP가 있으므로 (1) 유저의 정보를 클라이언트 서버가 들고있지 않아도 되어 보안 상의 문제가 깔끔하게 해결된다 (2) 회원가입 스테이지를 생략하고 바로 유저를 생성해 손쉽게 서비스를 이용할 수 있다 인 것으로 알고 있는데요, 참고 상렬님이 말씀하신대로 하면 이러한 이점들이 퇴색되지 않나 싶습니다. 실제로 애플 앱스토어 심사를 할 때는 애플 로그인 버튼에 '회원가입'이라는 표현을 쓰면 심사가 기각당하고 'Sign In with Apple'이라는 문구를 꼭 넣어야 하는데, 이러한 것들을 고려해봤을 때 회원가입 프로세스를 서버에서 자체적으로 처리하는게 소셜 로그인의 best practice라고 생각합니다.

이와 별개로 ktlint 에러와 디테일안 에러 핸들링은 오늘 주말 중으로 커밋하도록 하겠습니다.

[Hank-Choi]

Mono/Flux의 혼용은 이 레포를 참고했습니다.

레포가 아닌데요??

[davin111]

@subeenpark-io lint 성공시킨 채로 PR 준비해주시면 좋을 거 같아요!