여러 종류의 소셜 로그인을 위한 ERD 고찰

2024년 01월 06일 TIL

프로젝트를 진행하며 여태 서비스 내에서 jwt 발급을 이용한 로그인 구현만 다뤄보았다.
이번에 진행할 프로젝트에서는 실제 서비스를 가정하여 타겟층이 대부분 가지고 있을것이라 판단한
github, google, naver, kakao 네 종류의 도메인으로 소셜 로그인을 구현하려고 했었다.

소셜로그인

고찰 0

헌데, 시작 전부터 문제가 생겼다.
네이버는 사업자로 등록되어 있지 않으면 소셜 로그인을 위한 api를 제공하지 않는다는 것.
네이버는 빼기로 했다.
기왕 빼는거 카카오도 빼고 순수하게 개발자만을 위한 느낌으로 github와 google만 챙기기로 했다.

고찰 1

유저가 가입할 때 가입하는 도메인이 다른 부분을 착안해 이메일을 아이디로 사용하는 의견이 나왔다.

그러나 github은 가입할 때 @google.com로 가입하는 경우가 많으며 심지어는 google은 계정을 만들 때
타 도메인을 @google.com대신 이용할 수 있다.
google 계정인 주제에 @naver.com 를 달고 있는 별난 경우가 있을 수 있다.

따라서 다른 방법을 고민하기로 한다.

고찰 2

User 테이블을 생성할 때 user의 계정이 어떤 도메인을 통해 가입한 것인지 구분할것인지 고민했다. 첫 번째 아이디어는 아이디와 도메인을 복합키로 가져가기 였다.

User			유저
🔑	user_id	유저id	Long
	google		Boolean
	github		Boolean
	kakao		Boolean
	naver		Boolean
	user_email	유저이메일	String

이 아이디어는 얼마 지나지 않아 기각 됐다.
오라클에선 boolean 타입을 지원하지 않는다는 이유였다.

조사를 하면서 알게 된 부분이지만 char(1) 로 0 or 1 을 이용하여 대체하여 사용하는 방법이 있다.
그러나 당시에는 여기까지 고려하지 않았으며, 지금 시점에서 생각해봐도 굳이 이 방법을 쓸 이유는 없다고 생각한다.

고찰 3

현 시점에선 naver와 kakao를 제외하고 google과 github만 남았다. 따라서

User			유저
🔑	user_id	유저id	Long
	google_id	구글Oauth	String
	github_id	깃허브Oauth	String

형태로 인증 형태에 따른 Oauth 인증 아이디를 저장하는 부분까지 아이디어가 결정되었다.

고찰 4 (진행중)

도메인 과 해당 도메인에서 넘어오는 Oauth 를 복합키로 엮어 사용할 경우를 고려하고 있다.
이렇게 이용할 경우 github와 google 로그인과 email의 연관 관계를 굳이 설정할 이유가 사라지며
테이블 구조를 좀 더 간단하면서 효율적이게 축소할 수 있으리라 기대한다.
회의를 통해 의견을 제안해볼 예정이다.