요 며칠간 소셜 로그인을 구현하는 방식에 대해 찾아보고 고민해 본 결과를 정리합니다.
소셜 로그인
소셜 로그인이란 저희가 서비스에 가입할 때 흔히 보는 애플 로그인, 네이버 로그인, 카카오 로그인등을 의미합니다. 이러한 소셜 로그인들은 많은 수는 OAuth2.0이라 하는 프로토콜에 따라서 로그인을 방식을 제공하고 있습니다.
대략적인 OAuth 과정은, 유저가 소셜 서비스 제공 사이트에서 로그인을 하고 하면 유저의 소셜 서비스에서의 정보를 가져올 수 있게 되고, 이를 통해 자체적으로 로그인/유저 서비스를 만들고 제공하는 느낌입니다.
여기서 말할 점은 결국 소셜 서비스에서 모든 것을 제공해주지 않고, 실제 유저 기능은 자체적으로 구현을 해야 한다는 점입니다. 이를 도와주는 많은 라이브러리도 제공되고 있어 이러한 것들을 사용하는 것도 좋습니다.
이번 글에서는 이런 라이브러리들이 어떤 방식으로 소셜 로그인을 제공하는지를 분석하고, 소셜 로그인 구현시 DB를 어떤 방식으로 작성하는지에 대해 정리한 글을 작성합니다.
DB 설계 방식
유저 판별 방법
유저가 소셜로그인을 하면 소셜 서비스의 유저 정보를 제공받습니다. 그럼 이 제공받은 소셜 플랫폼의 정보를 토대로 서비스의 유저와 연결하고 판별하여야 합니다. 이때 어느 정보를 기준으로 유저를 구분할 것인지 다양한 구현 방법이 존재합니다.
이메일
이메일로 유저를 판별하는 방식입니다.
장점
- 이메일은 대부분의 소셜 플랫폼에서 제공하는 대중적인 정보입니다.
- 이메일은 고유하여 유저가 자기 스스로임을 증명하기 간단합니다.
단점
- 소셜 플랫폼에서 유저가 이메일을 실제로 소유하는지 제대로 검증하지 않을 수 있습니다. 이 경우에 자체적으로 추가 인증이 필요합니다.
- 소셜 플랫폼에 등록되어 있는 이메일이 바뀔 수 있습니다. 이경우에 이메일 만으로 유저를 판별한다면 유저는 계정을 잃어버릴 수 있습니다.
- 이메일을 기본적으로 제공하지 않는 소셜 플랫폼이 있습니다. 예로 페이스북은 기본적으로는 전화번호로 가입을 받고 있습니다. 또한 카카오도 추가적인 신청을 하지 않으면 이메일 획득을 강제할 수 없습니다.
플랫폼 고유 아이디
플랫폼 고유 아이디로 유저를 판별하는 방식입니다. 소셜 로그인 제공 플랫폼별로 다르게 제공하는 unique한 키를 판별자로 사용하는 것입니다.
장점
- 소셜 로그인 제공 플랫폼에서 이메일등을 변경해도, 각 플랫폼 고유의 아이디로 인증하기에 상관없습니다.
단점
- 따로 고유한 키를 제공하지 않는 플랫폼이 있을 수 있습니다.
DB구조
적당한 유저 판별 키를 설정했다면, DB구성 방식을 결정해야 합니다.
이메일만 사용
이 경우는 소셜 로그인의 대부분의 기능을 사용하지 않고, 오직 이메일만 로그인 시에 사용하는 방법입니다.
작동 방식은 유저 필드에 이메일을 필드를 하나 추가하고, 매 소셜 로그인 시에 이메일 값만 받아와서 그 즉시 인증하고, 다른 소셜 데이터는 따로 저장하거나 사용하지 않는 방식입니다.
이 경우에는 소셜 로그인에 대하여 저장하는 것이 없기에, 해당 아이디가 어느 소셜 플랫폼과 연결되었는지 알 수 없고(실제로 연결이 안 돼있는 것과 마찬가지 이기도 하고), 플랫폼에서 이메일 인증절차를 제대로 걸치지 않는다면, 보안적으로도 상당한 문제가 있는 방식입니다. 이메일을 속이는 것 만으로 로그인 인증이 가능하니 말이죠.
다만 이메일만 저장하니, DB 구성자체는 쉽고, 다중 소셜 로그인도 구현하기 매우 편한 방식입니다.
유저 테이블에 작성
유저 테이블에 플랫폼의 종류를 저장하는 platform_type, 그리고 유저 구별 필드인 이메일 또는 플랫폼 고유 값 필드 platform_id 등을 추가하여 소셜 로그인을 구현하는 방식입니다.
유저 모델에 작성하기 때문에 유저 계정 하나당 소셜 로그인도 하나로 제한이 되어 다중 소셜 로그인 구현은 어렵습니다.
추가적인 테이블 작성
이 방식은 추가적인 소셜 로그인 정보 관리용 테이블을 만들고 이를 1:1 또는 1:N으로 연결하는 방식입니다. 이때 1:N으로 연결할 시에는 다중 소셜 로그인을 구현할 수 있습니다.
유저와 연결되는 소셜 로그인 관리용 테이블은 platform_type, platform_id 등의 정보 등을 가지는 것으로 구현할 수 있습니다. 또는 이경우에도 이메일을 구별 수단으로 사용할 수 있습니다.
또한 인증 관련 정보뿐만이 아닌, 각 소셜 플랫폼에서 나오는 정보들을 위해 확장하기도 편합니다.
실제 사용되는 방식(라이브러리 등)
dj-rest-auth & django-allauth
Spring Security OAuth
레퍼런스
https://rastalion.me/회원-가입-및-로그인을-위한-테이블-설계/
'기타 (Other)' 카테고리의 다른 글
MacOS 루트 디렉토리 정리 (0) | 2023.08.30 |
---|---|
카카오 로그인에서 프론트와 백엔드, 어디서 구현해야 할까? (0) | 2023.07.31 |
LF vs CRLF (0) | 2023.05.14 |
AWS CodeWhisperer 사용기 (0) | 2023.04.29 |
시맨틱 버저닝(Semantic Versioning) 정리 (0) | 2022.09.18 |