지난 포스트인 객체지향적 JWT 인증 처리 및 커스텀 리졸버/인터셉터 도입에 이어 확장 가능한 객체지향적 OAuth 구조 설계 및 카카오 소셜 로그인을 구현하였다.
개요
객체지향적 OAuth 구조 설계 및 구현
OAuth를 통한 사용자 정보 획득 및 서버 회원 계정 연결 로직 구현
카카오 소셜 로그인 기능 추가
확장 가능한 객체지향적 OAuth 구조를 설계하고, 카카오 소셜 로그인 기능을 구현하여 사용자 경험을 개선하는 데 중점을 두었습니다. 추후 다른 소셜 로그인 제공자 추가 시에도 최소한의 변경으로 확장이 가능한 구조로 설계되었습니다.
배경
- 사용자 편의성을 위해 소셜 로그인 기능 필요
- 추후 다양한 OAuth 제공자(Google, Naver 등)의 유연한 확장을 고려한 설계 필요
- 웹/모바일 등 다양한 디바이스에서의 로그인 지원 필요
변경된 점
1. OAuth 관련 도메인 설계
- Feat: OAuthProvider 정의 [OAuthProvider] 열거형: 소셜 로그인 제공자(KAKAO, APPLE) 관리
- Feat: OAuthToken 정의 [OAuthToken]: 액세스 토큰, 리프레시 토큰 등 소셜 로그인 인증 정보 관리
- Feat: OAuthUserInfo 정의 [OAuthUserInfo]: 소셜 로그인 사용자 정보(ID, 이메일, 이름) 객체화
2. OAuth 서비스 계층
- Feat: OAuthService 인터페이스 추가 [OAuthService] 인터페이스: 모든 OAuth 제공자(Apple 제외) 가 구현해야 할 기본 계약 정의
- getUserInfo: 인증 코드로 사용자 정보 조회
- getRedirectUrl: OAuth 로그인 페이지 URL 반환
- isBackendRedirect: 백엔드 리다이렉트 지원 여부
- Feat: OAuthService의 구현체 KakaoOAuthService 구현 [KakaoOAuthService]: 카카오 OAuth 구현체
- 카카오 인증 토큰 발급 및 사용자 정보 조회 로직
3. OAuth 매핑 엔티티 구현
- Feat: OAuthMappingEntity 엔티티 추가 [OAuthMappingEntity]: OAuth 사용자와 서비스 사용자 간 매핑 관리
- Feat: OAuthMappingEntityDto 및 정적 생성자 구현 [OAuthMappingEntityDto]: 비즈니스 계층과 리포지토리 계층 간 데이터 전송
- Feat: OAuthRepository 인터페이스 추가[OAuthRepository]: OAuth 매핑 정보 CRUD 인터페이스
- Feat: OAuthRepository의 구현체 OAuthRepositoryImpl 구현 [OAuthRepositoryImpl]: JPA 기반 구현체
4. OAuth 로그인 로직 구현
- Feat: OAuthLoginService 구현 [OAuthLoginService]: 로그인 처리 및 회원 연결 로직 구현
- OAuth 제공자 동적 선택을 위한 Map 기반 서비스 관리
- 웹/앱 환경에 따른 리다이렉트 URL 처리
- 신규/기존 사용자 분기 처리
- JWT 토큰 발급 및 관리
5. OAuth 컨트롤러
- Feat: Oauth Controller 구현 [OAuthController]: OAuth 관련 API 엔드포인트 제공
auth/oauth/{provider}/login: 소셜 로그인 페이지로 리다이렉션
auth/oauth/{provider}/callback: OAuth 콜백 처리
6. 회원가입 연동
- Feat: UserService에 Oauth 비즈니스 로직 연동 [UserService]: 소셜 로그인 후 신규 사용자의 경우 회원가입 절차 연계
- Feat: UserController에 추가된 비즈니스 로직 기반 수정 및 리턴타입에 SuccessResponse 도입 [UserController]: 회원가입 API와 OAuth 매핑 연결
OAuth 회원가입 흐름 정리
- Notion 정리글: NEWZET OAuth(카카오) 회원가입 흐름 상세 정리
기술적 특징
- 전략 패턴 활용: OAuth 서비스 구현에 전략 패턴을 적용하여 다양한 소셜 로그인 제공자를 쉽게 확장 가능하도록 설계
- 의존성 주입: 스프링 의존성 주입을 활용한 느슨한 결합 구조
- 캡슐화: 도메인 모델에서 내부 상태 변경 로직 캡슐화
- 테스트 코드: 철저한 단위 테스트 작성으로 코드 품질 보장
특이사항
Chore: 프로젝트 환경설정에 oauth관련 환경변수 세팅 에서 PostgreSQL prepareThreshold=0으로 설정한 이유
- Notion 정리글: PostgreSQL prepareThreshold=0 설정 이유
요약:
prepareThreshold=0설정은 일단 문제를 회피하기 위한 임시 조치이며,
추후 다음과 같은 방향으로 개선할 예정- 쿼리 캐시 전략 개선 혹은 수동 prepare statement 사용 방식 고려
- 반복 쿼리를 줄이거나 배치 방식 개선
- JDBC 드라이버 및 Hibernate 설정을 조정하여 충돌 최소화
추가) 수정사항
1. 도메인 분리
원인: OAuthMappingEntity와 OAuthMappingEntityDto에 비즈니스 로직이 일부 포함되어있는 이슈를 발견
- OAuthMapping 도메인 클래스를 신규 생성하여 비즈니스 로직 담당
- OAuthMappingEntity는 JPA 엔티티로써 순수하게 영속성 관리만 담당하도록 변경
- OAuthMappingEntityDto를 순수 데이터 전달 객체(DTO)로 변환
2. 비즈니스 로직 수정
원인: 비즈니스 로직에서 기존 entityDto를 활용하던 로직이 존재
- OAuthLoginService 등에서 도메인 객체를 활용하도록 수정
3. repository 로직 수정
원인: repository impl단에서 엔티티 - dto - 도메인 을 통한 변환 후 수정하여 역순으로 변환하고 save하는 로직을 더티 채킹으로 간소화 가능
- OAuthRepositoryImpl 도메인을 거치지 않고 더티 채킹을 활용하도록 수정
4. 단위 테스트 추가
원인 : OAuthToken과 OAuthUserInfo 도메인에 대한 단위 테스트 부재
- OAuthToken과 OAuthUserInfo 도메인에 대한 유닛 테스트 추가
참고자료
해당 PR 에서도 확인하실 수 있습니다 ☺️
클라우드 데이터 플랫폼 주니어 개발자 도도입니다!