OAuth · 소셜 로그인

OAuth이란?

OAuth를 붙이면 로그인 화면보다 먼저 바뀌는 것이 비밀번호를 누가 책임지느냐입니다. 회원 DB에서 비밀번호 해시 컬럼이 사라지고, 그 자리에 제공사가 발급한 토큰과 사용자 식별값만 남습니다. 우리 서버가 털려도 남의 서비스 비밀번호는 나가지 않고, 2단계 인증·이상 로그인 탐지·기기 관리처럼 손이 가장 많이 가는 보안 기능을 제공사 수준으로 빌려 쓰게 됩니다. 회원 시스템에서 유지보수 부담이 큰 영역이 통째로 빠지는 셈입니다.

실무에서 자주 흔들리는 경계가 하나 있습니다. OAuth 2.0은 인증이 아니라 인가 프로토콜입니다. '이 사람이 누구인가'를 확인하는 일은 그 위에 얹은 OpenID Connect의 ID 토큰이 맡고, OAuth가 주는 액세스 토큰은 '이 앱이 어디까지 손대도 되는가'를 적은 이용권입니다. 토큰에는 범위(scope)와 유효기간이 붙는데, 액세스 토큰은 보통 한 시간 안팎, 리프레시 토큰은 수 주에서 수 개월로 잡습니다. 방식도 갈려서, 지금 웹·앱 권고안은 인가 코드에 PKCE를 더한 조합이고 브라우저로 토큰을 그대로 던지던 임플리시트는 빠졌습니다.

국내 서비스라면 제공사별 차이도 미리 따져야 합니다. 카카오는 이메일이 선택 동의 항목이라 비즈니스 앱 전환과 검수를 거쳐야 받을 수 있고, 애플 로그인은 이용자가 '이메일 가리기'를 고르면 실제 주소 대신 임의의 릴레이 주소가 넘어옵니다. 구글·네이버까지 붙이면 같은 사람이 채널만 바꿔 계정을 서너 개 만들게 되므로, 이메일이 아니라 제공사별 고유 식별자를 기준 키로 삼는 규칙을 먼저 잡지 않으면 나중에 회원 병합 작업에 몇 배가 듭니다.

사고는 대개 두 군데서 납니다. 첫째, 액세스 토큰을 신원 증명서로 오해해 '토큰이 오면 로그인 성공'으로 처리하는 경우입니다. 다른 앱에서 받은 토큰을 그대로 밀어 넣으면 남의 계정으로 들어올 수 있어서, ID 토큰의 발급처와 대상(aud) 검증을 빼면 그대로 뚫립니다. 둘째, 소셜 로그인만 달랑 붙여 두는 경우입니다. 제공사 점검이나 정책 변경으로 30분만 막혀도 전 회원이 서비스에 못 들어오고, 이용자가 연동을 해제하면 결제 이력이 달린 계정이 주인 없이 남습니다. 대체 로그인 수단을 최소 한 가지는 남겨 두는 것이 원칙이며, 동의 창에서 쓰지도 않을 권한까지 긁어모으면 검수에서 반려되거나 동의율이 눈에 띄게 떨어집니다.