Member 중에서 인증에 필요한 필드(role, account_id)등을 따로 빼서 AuthUser로 사용했었는데, 해당 필드들이 인증에만 사용되지 않아서 Member 의 도메인과 겹치게 되는 경우가 발생했습니다. -> 다시 Member로 합쳤습니다.
기존 OAuth2 인증의 시작지점과 종료지점이 backend 였는데(jsp 처럼), 안드로이드까지 들어오면서 시작과 종료지점이 frontend 로 변경되어야 합니다.(프론트에서 api 요청하고 결과를 받을 수 있게,) 따라서 전자의 방식에서 필연적이었던 OAuth2 인증 및 리다이렉트 관련 로직을 전부 삭제했습니다.
인증로직을 전부 묶어서 모듈로 빼버렸습니다. 회원 서비스와의 상호 의존성이 높아지는 것을 강제로 방지하기 위함입니다. 리소스 서버는 인증모듈을 의존하지만, 거꾸로 될 수는 없습니다.
Member - MemberSocialAccount - SocialAccount 와 같이 중간 객체 이용해서, 사용자와 소셜계정을 1:N 으로 연동합니다. SocialAccount 는 인증 모듈에만 속하는 엔티티입니다. Member와 MemberSocialAccount는 리소스서버에 속하는 엔티티입니다.
Member중에서 인증에 필요한 필드(role, account_id)등을 따로 빼서AuthUser로 사용했었는데, 해당 필드들이 인증에만 사용되지 않아서Member의 도메인과 겹치게 되는 경우가 발생했습니다. -> 다시 Member로 합쳤습니다.OAuth2인증의 시작지점과 종료지점이backend였는데(jsp 처럼), 안드로이드까지 들어오면서 시작과 종료지점이frontend로 변경되어야 합니다.(프론트에서 api 요청하고 결과를 받을 수 있게,) 따라서 전자의 방식에서 필연적이었던OAuth2인증 및 리다이렉트 관련 로직을 전부 삭제했습니다.Member-MemberSocialAccount-SocialAccount와 같이 중간 객체 이용해서, 사용자와 소셜계정을 1:N 으로 연동합니다.SocialAccount는 인증 모듈에만 속하는 엔티티입니다.Member와MemberSocialAccount는 리소스서버에 속하는 엔티티입니다.see : #97, #101, Inhabas/Inhabas.com#102