통합 로그인 DB 설계: 일반 + 소셜

주의: 이 글은 DB 설계에 대한 일반적인 접근 방식을 다루고 있습니다. 실제 프로젝트에 적용 시 요구사항과 상황에 맞게 적절히 수정하여 사용하세요.

소개

현대의 웹 애플리케이션은 다양한 인증 방식을 지원해야 합니다. 이 글에서는 일반 로그인과 소셜 로그인을 동시에 지원하는 통합 인증 시스템의 데이터베이스 설계와 워크플로우를 설명합니다.
이 설계는 향후 2FA(Two-Factor Authentication)와 같은 추가적인 인증 체계를 쉽게 통합할 수 있는 확장성 있는 구조를 가지고 있습니다.

데이터베이스 설계

1. 사용자 정보 테이블 (users)

모든 사용자의 기본 정보를 저장합니다.

필드명	데이터 타입	제약 조건	설명
idx	INT	PRIMARY KEY, AUTO_INCREMENT	사용자의 고유 식별자
name	VARCHAR(100)	NOT NULL	사용자 이름
email	VARCHAR(255)	NOT NULL, UNIQUE	이메일 주소
phone_number	VARCHAR(20)	NOT NULL, UNIQUE	전화번호
created_at	TIMESTAMP	DEFAULT CURRENT_TIMESTAMP	계정 생성 시간

2. OAuth2 Provider 관리 테이블 (oauth2_providers)

지원하는 OAuth2 제공자(예: Google, Facebook, GitHub 등)의 정보를 관리합니다.

필드명	데이터 타입	제약 조건	설명
idx	INT	PRIMARY KEY, AUTO_INCREMENT	제공자의 고유 식별자
name	VARCHAR(50)	NOT NULL, UNIQUE	제공자 이름 (예: "Google", "Facebook")
activation	BOOLEAN	NOT NULL, DEFAULT TRUE	해당 제공자의 활성화 상태

3. 사용자-OAuth2 연동 관리 테이블 (user_oauth_connections)

사용자와 OAuth2 제공자 간의 연결을 관리합니다.

필드명	데이터 타입	제약 조건	설명
idx	INT	PRIMARY KEY, AUTO_INCREMENT	연결의 고유 식별자
user_idx	INT	FOREIGN KEY (users.idx)	사용자의 고유 식별자
provider_idx	INT	FOREIGN KEY (oauth2_providers.idx)	OAuth2 제공자의 고유 식별자
oauth2_user_id	VARCHAR(255)	NOT NULL	OAuth2 제공자에서 제공하는 사용자 ID
created_at	TIMESTAMP	DEFAULT CURRENT_TIMESTAMP	연동 생성 시간

UNIQUE KEY (user_idx, provider_idx)

4. 사용자 자격 증명 관리 테이블 (user_credentials)

일반 로그인에 사용되는 사용자의 ID와 비밀번호를 관리합니다.

필드명	데이터 타입	제약 조건	설명
idx	INT	PRIMARY KEY, AUTO_INCREMENT	자격 증명의 고유 식별자
user_idx	INT	FOREIGN KEY (users.idx)	사용자의 고유 식별자
id	VARCHAR(50)	NOT NULL, UNIQUE	사용자 로그인 ID
password	VARCHAR(255)	NOT NULL	bcrypt로 해시된 비밀번호
last_updated	TIMESTAMP	DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP	마지막 업데이트 시간

인증 워크플로우

소셜 로그인 워크플로우

1. 사용자가 소셜 로그인(예: Google, Facebook 등)을 통해 인증을 시도합니다.
2. 소셜 플랫폼에서 사용자 정보(이메일, 이름, 전화번호 등)를 받아옵니다.
3. 받아온 전화번호를 기준으로 users 테이블에서 기존 사용자를 검색합니다.
4. 기존 사용자가 존재하는 경우:
   a. user_oauth_connections 테이블에서 해당 사용자와 OAuth2 제공자의 연결 정보를 확인합니다.
   b. 연결 정보가 이미 존재하면 바로 로그인을 진행합니다.
   c. 연결 정보가 없으면 user_oauth_connections 테이블에 새로운 연결 정보를 추가한 후 로그인을 진행합니다.
5. 기존 사용자가 존재하지 않는 경우:
   a. users 테이블에 새로운 사용자 정보를 추가합니다.
   b. user_oauth_connections 테이블에 새로운 연결 정보를 추가합니다.
   c. 새로 생성된 사용자 정보로 로그인을 진행합니다.

일반 로그인 워크플로우

1. 사용자가 ID와 비밀번호를 입력하여 로그인을 시도합니다.
2. user_credentials 테이블에서 입력된 ID와 일치하는 레코드를 찾습니다.
3. 레코드가 존재하는 경우:
   a. 저장된 해시된 비밀번호와 입력된 비밀번호를 비교합니다.
   b. 비밀번호가 일치하면 로그인을 승인합니다.
   c. 비밀번호가 일치하지 않으면 로그인을 거부합니다.
4. 레코드가 존재하지 않는 경우, 로그인을 거부합니다.

새 사용자 등록 워크플로우 (일반 로그인)

1. 사용자가 회원가입 양식을 작성합니다 (이름, 이메일, 전화번호, ID, 비밀번호 등).
2. 입력된 ID, 이메일, 전화번호의 중복을 확인합니다.
3. 중복이 없는 경우:
   a. users 테이블에 새로운 사용자 정보를 추가합니다.
   b. user_credentials 테이블에 ID와 해시된 비밀번호를 저장합니다.
4. 중복이 있는 경우, 사용자에게 다른 정보를 사용하도록 요청합니다.

확장성 및 향후 계획

이 데이터베이스 구조와 인증 시스템은 다음과 같은 이점을 제공합니다:

1. 유연한 인증 방식: 사용자는 일반 로그인과 소셜 로그인을 자유롭게 선택하여 사용할 수 있습니다.
2. 쉬운 OAuth2 제공자 추가: 새로운 OAuth2 제공자를 oauth2_providers 테이블에 추가하는 것만으로 지원이 가능합니다.
3. 2FA 통합 준비: 사용자 테이블과 분리된 자격 증명 관리를 통해, 2FA와 같은 추가 인증 방식을 쉽게 도입할 수 있습니다.

2FA 통합 예시 (user_2fa 테이블)

향후 2FA를 도입할 경우, 다음과 같은 테이블을 추가할 수 있습니다:

필드명	데이터 타입	제약 조건	설명
idx	INT	PRIMARY KEY, AUTO_INCREMENT	2FA 설정의 고유 식별자
user_idx	INT	FOREIGN KEY (users.idx), UNIQUE	사용자의 고유 식별자
secret_key	VARCHAR(32)	NOT NULL	2FA 비밀 키
is_enabled	BOOLEAN	NOT NULL, DEFAULT FALSE	2FA 활성화 여부
created_at	TIMESTAMP	DEFAULT CURRENT_TIMESTAMP	2FA 설정 시간
last_used_at	TIMESTAMP	NULL	마지막 2FA 사용 시간

2FA 워크플로우

2FA 설정

1. 사용자가 2FA 설정을 요청합니다.
2. 시스템은 고유한 secret_key를 생성합니다.
3. 생성된 secret_key를 QR 코드로 변환하여 사용자에게 표시합니다.
4. 사용자가 인증 앱(예: Google Authenticator)으로 QR 코드를 스캔합니다.
5. 사용자가 인증 앱에서 생성된 코드를 입력하여 확인합니다.
6. 확인이 성공하면, user_2fa 테이블에 사용자의 정보를 추가하고 is_enabled를 TRUE로 설정합니다.

2FA를 사용한 로그인

1. 사용자가 일반 로그인 또는 소셜 로그인을 통해 1차 인증을 완료합니다.
2. 시스템은 user_2fa 테이블에서 해당 사용자의 2FA 활성화 여부를 확인합니다.
3. 2FA가 활성화되어 있다면:
   a. 사용자에게 2FA 코드 입력을 요청합니다.
   b. 사용자가 인증 앱에서 생성된 코드를 입력합니다.
   c. 시스템은 입력된 코드의 유효성을 검증합니다.
   d. 검증이 성공하면 로그인을 완료하고, 실패하면 로그인을 거부합니다.
4. 2FA가 비활성화되어 있다면, 추가 인증 없이 로그인을 완료합니다.

결론

이러한 구조를 통해 시스템의 확장성과 유지보수성을 높일 수 있으며, 향후 새로운 인증 요구사항에 유연하게 대응할 수 있습니다.