서로 다른 소셜 로그인으로 받은 이메일 주소가 같습니다. 기존 서비스 계정에 새 로그인 수단을 자동으로 연결해도 되나요?

이메일 주소가 같다는 이유만으로 소셜 로그인 수단을 자동 연결해서는 안 됩니다. 연결은 단순히 프로필을 합치는 일이 아니라 새 자격으로 기존 계정에 들어갈 권한을 추가하는 작업이기 때문입니다. 공급자가 이메일을 검증했는지, 주소가 현재도 그 사용자의 것인지, 두 인증 결과가 같은 사람의 의도적인 연결 요청으로 묶였는지를 각각 확인해야 합니다. 같은 문자열은 속성의 일치일 뿐 소유권 증명이 아닙니다. 이런 식으로 인증 수단을 기존 계정에 추가하는 과정을 계정 연결 (account linking)이라고 부릅니다.

연결 흐름과 증거를 분리합니다

가장 안전한 기본 흐름은 이미 로그인한 사용자가 설정 화면에서 ‘로그인 수단 추가’를 시작하는 것입니다. 서버는 현재 세션의 계정 ID를 검증하고, 민감한 계정이라면 최근 비밀번호나 MFA 재인증을 요구합니다. 이어서 새 공급자의 authorization code를 별도의 연결 시도 ID에 묶어 교환하고, 그 결과의 issuer와 공급자 내부의 안정적인 subject를 확인합니다. 이메일은 표시·알림·검색에 활용할 수 있지만, 연결의 영구 키는 보통 issuer와 subject의 조합으로 둡니다. 콜백이 다른 브라우저 세션이나 다른 계정에서 시작된 요청에 붙지 않도록 state와 연결 시도 만료도 검증합니다.

새 공급자가 ‘email_verified’를 제공하더라도 그 의미와 정책을 공급자별로 확인해야 합니다. 오래된 주소, 조직 관리 주소, 재할당 가능한 주소는 동일인 판정의 충분조건이 아닙니다. 자동 연결을 제공하고 싶다면 기존 계정으로 먼저 로그인하게 하거나, 두 자격으로 각각 인증한 뒤 사용자에게 어떤 계정과 어떤 로그인 수단이 연결되는지 명시적으로 확인하게 하겠습니다. 계정 병합은 데이터 소유권과 결제·제재 규칙까지 바꾸므로 연결과 한 단계로 처리하지 않습니다.

충돌과 해제를 안전하게 처리합니다

새 자격이 이미 다른 서비스 계정에 연결돼 있으면 임의로 옮기거나 조용히 병합하지 않고 충돌로 멈춥니다. 사용자가 두 계정을 모두 소유한다는 별도 증명이 있고, 구매·보상·제재 같은 데이터의 병합 규칙이 정해진 경우에만 별도 병합 절차로 넘깁니다. 연결 레코드에는 issuer·subject에 유일 제약을 두어 동시에 보낸 두 요청이 같은 자격을 각각 차지하지 못하게 합니다. 연결 시도 자체도 한 번만 소비되는 상태와 요청 ID를 가져야 합니다.

연결 해제는 남은 로그인 수단 수, 복구 수단, 최근 인증 시점을 확인한 뒤 허용하겠습니다. 마지막 수단을 제거하면 계정 잠금이 되므로 새 수단 등록이나 복구 코드 발급을 먼저 요구할 수 있습니다. 검증은 같은 이메일을 가진 서로 다른 공급자 사용자, 변경된 이메일, 오래된 콜백, 중복·동시 연결, 이미 연결된 자격, 해제 직후 로그인을 재현합니다. 성공 여부보다 새 자격이 정확히 한 계정에만 연결되고 사용자의 명시적 의도 없이 권한이 늘지 않는지가 기준입니다.

연결 전에 사용자가 이미 다른 계정에 로그인한 상태인지도 서버가 확인하겠습니다. 브라우저에 남은 공급자 세션만 믿으면 사용자가 의도하지 않은 계정이 선택될 수 있으므로, 연결 확인 화면에서 공급자 표시명과 우리 계정의 일부 식별 정보를 다시 보여 주고 민감한 계정은 최근 인증을 요구합니다. 연결 완료 이벤트에는 어떤 자격이 어느 계정에 추가됐는지와 요청 주체를 남겨, 고객지원이 임의로 계정을 합치지 않고 감사할 수 있게 하겠습니다. 이메일을 변경하거나 공급자가 검증 상태를 철회한 경우에는 다음 로그인에서 곧바로 계정을 옮기지 않고 재인증 또는 연결 재검토를 요구하겠습니다. 이렇게 하면 편의성은 유지하면서도 ‘같은 이메일’이라는 약한 신호가 권한 부여로 승격되는 경로를 차단할 수 있습니다.