다양한 Oauth2 Provider 들을 다룰 수 있는 코드 만들기

 

Oauth2 관련 작업을 하면 어딘가 비슷한 패턴이 계속 반복되기 때문에 어떻게 코드를 써야될지 고민을 많이 하게됩니다.

이번에는 작성해둔 코드가 어딘가 아쉬움이 느껴져서 나름대로 개선을 해봅니다.

사용측 코드가 완성된 상태가 아니기 때문에 흐름을 참고하는 용도로 봐주시면 좋겠습니다.

---

 

이번 글은 다음의 순서로 작성되었습니다.

1. 개선 이전의 코드

2. 개선 이후의 코드

3. 정리하기

 

 

1. 개선 이전의 코드

개발자 유미님의 채널에 스프링 시큐리티 관련한 구현 영상들이 많이 있어서 참고를 하였습니다 ( 개발자 유미 채널 )

Oauth2 로그인 과정에서 User 관련 로직을 커스텀하기 위해서 CustomOauth2UserService를 만들어보았습니다.

인터페이스만 상속받아서 구현할까 상속을 받을까 고민을 해보았는데, 이미 Oauth2 client에서 구현체를 제공하고 있기 때문에 상속받아서 super를 사용하였습니다.

 

 

각 provider 별로 처리해줘야할 내용이 다르기 때문에 내용을 별도로 분리해서 처리해보았습니다.

이런 형태는 새로운 프로바이더가 추가될 때 마다 새로운 메소드와 else if 문이 추가되어야하는 구조입니다.

 

어딘가 '자바'스럽지 못한 코드라는 느낌과 팩토리 메소드 패턴으로 개선이 가능할 것 같다는 느낌이 듭니다.

 

 

2. 개선 이후의 코드

팩토리 메소드 패턴의 핵심은 생성과 비즈니스 로직을 분리하는데 있다고 이해하고 있습니다.

따라서 지금 메소드로 구현되어있는 개별 비즈니스 로직을 먼저 클래스로 분리해보겠습니다.

 

1. 비즈니스 로직 처리하는 Provider 클래스 구현

분리하기에 앞서서 여러 개의 Provider가 생길 것이니 공통적으로 구현해야할 형태를 interface로 정의해줍니다.

 

 

우선 네이버 관련 로직을 분리해줍니다.

 

다음은 구글 관련 로직입니다.

두 프로바이더가 제공하는 유저 정보 response의 값이 다르기 때문에 유저 정보를 가져오는 로직이 아주 약간 달라집니다.

 

2.  Provider를 생산하는 팩토리 구현

지금까지는 비지니스 로직을 다루는 Provider를 구현했습니다.

기존 코드를 개선해서 provider에 따라 적절한 비지니스 로직을 제공하는 팩토리를 만들어보겠습니다.

 

이전의 모습도 어느정도 팩토리의 역할을 하고 있었지만 보다 개선을 해보겠습니다.

개선 전

 

 

생성자에서 각종 Provider를 주입받아서 Map으로 관리하겠습니다.

그리고 요청이 들어오는 프로바이더명에 맞는 프로바이더를 제공합니다.

 

기존에 있던 if / else 중첩 구문이 좀 단순하게 변경된 것은 장점인데 생성자가 조금 복잡해진 감도 있는 것 같습니다.

개선 후

 

3.  사용처의 변경사항

개선 전의 코드를 보면 어느 정도 로직이 분리는 되어있습니다.

getOauth2AuthUser 라는 메소드를 통해서 parsing된 유저 정보를 받고 있었습니다.

 

개선 전

 

사용 측에서 살펴보았을 때는 큰 변화가 눈에 띄지는 않습니다.

하지만 인자 2개가 넘어가던 부분이 1개로 변경된 것을 볼 수 있습니다.

이건 2개의 일을 하던걸 1개의 일을 하게 된것으로 볼 수도 있지 않을까 합니다 ㅎㅎ

개선 후

 

 

3.  정리하기

현 시점에서는 다소 오버엔지니어링일 수도 있겠지만, 이후에 다른 작업을 하다가 다시 확장을 고려한 설계로 변경을 하려고 하면 코드를 다시 살펴봐야할 것이기 때문에 ... 지금 기억이 있을 때 어느정도 확장성을 가져갈수 있는 코드를 구현해 두었습니다.

 

감사합니다.