9개 브랜드 아이덴티티 플랫폼에 걸친 검증된 양방향 계정 연결

그 유연성은 정체성 문제를 야기했습니다. 고객이 기존 계정에 속한 이메일의 새 Apple 또는 Google 신원으로 로그인하면, 플랫폼은 어떻게 할지 결정해야 했습니다. 이메일 매칭만으로 두 사람을 자동으로 연결하는 것은 안전하지 않습니다: 이메일 주소가 일치하면 관계가 있을 수 있지만, 로그인자가 실제로 그 받은편지함을 통제한다는 증거는 아닙니다. 플랫폼은 호환되는 애플과 구글 신원을 하나의 공유 계정에 연결하면서도 이메일 매칭에 단독으로 접근 권한을 부여하지 않고, 애플의 사설 중계 주소, 비밀번호 지원 계정, 위험한 로그인, 제공업체 장애 등 난처한 사례를 포함해 9개 브랜드 모두에서 일관되게 이 방식을 적용할 필요가 필요했습니다.

제약은 구체적이었다. 링크는 양방향이고 순서에 상관없이 이루어져야 했습니다: 구글이 먼저 시작되고 애플이 먼저 연결되거나, 애플이 먼저 다음 구글이 같은 공유 계정에 도달해야 했습니다. 애플의 '내 이메일 숨기기'는 고객의 실제 이메일 이메일과 일치하지 않는 프라이빗 릴레이 주소가 조용히 그 계정에 연결되어서는 안 되기 때문에 별도로 처리되어야 했습니다. 검증은 이미 높은 위험 인증에 신뢰받던 동일한 코드 챌린지 메커니즘을 재사용해야 했기에, 새로운 통제를 발명하기보다는 상속받은 검증된 통제 장치를 연결해야 했습니다. 위험은 마찰을 조절해야 했습니다: 저위험 로그인은 마찰 없이 유지되어야 하며, 중간, 고위험, 미확인 위험은 OTP가 필요했습니다. 반복적인 실패는 각 브랜드가 아닌 모든 브랜드에 적용되는 차단 정책을 통해 차단해야 했습니다. 그리고 제공업체 실패는 반드시 실패 방지 조치가 필요하며, 고객이 부분 또는 중복 계정을 남기지 않도록 해야 했습니다.

동일한 검증된 경로가 두 연결 방향을 모두 포함했습니다. 고객이 구글에서 계정을 만들고 같은 공유 이메일로 '애플과 계속 진행'을 선택하면, 시스템이 기존 계정을 감지하고 코드를 이메일로 보내고 성공적인 인증 후 애플과 연결했습니다. 반대로, 애플의 '내 이메일 공유'가 먼저 시작되고 구글은 같은 챌린지를 통해 동일한 공유 계정으로 해결되었습니다. 연결 후 고객은 Apple, Google 또는 설정된 이메일과 비밀번호로 로그인하여 같은 계정에 접속할 수 있었습니다.

애플의 '내 이메일 숨기기'는 의도적으로 별도의 경로를 유지했습니다. 개인 릴레이 주소가 고객의 비공개 개인 이메일과 일치하지 않으면, 해당 신원은 동일 이메일 연결 대상이 아니었습니다. 중계기를 관련 없는 계정에 연결하는 대신, 플랫폼은 제한된 접근 설명을 보여주고 별도의 중계 이메일 계정을 만들었습니다. 첫 번째 연결 외에도, 동일한 계정은 자체 라이프사이클을 가지고 있었습니다: 고객은 소셜 계정에 비밀번호를 설정하고, 기본 이메일을 변경할 수 있으며(이전 소셜 제공업체와의 연결이 해제되고 재인증이 필요), 모든 회귀 로그인은 세션 발급 전에 위험 평가를 거쳤습니다.

그 흐름은 명확히 경계가 있는 결과로 갈라졌습니다. 자격 있는 이메일 매칭이 기존 계정의 이메일로 연결 코드를 발급했으며; 검증이 성공하면 제공업체가 연결되었고, 실패하면 시도가 거부되어 기록되었습니다. 일치하지 않는 애플 릴레이 이메일은 제한된 접근 설명과 별도의 릴레이 이메일 계정으로 라우팅되었습니다. 공유 크로스 브랜드 계정으로 해결되면 계정 상태를 확인했습니다: 차단된 계정은 차단된 것으로 표시되었고, 활성 계정은 위험 등급으로 분류되었습니다. Low Risk는 인증된 세션을 직접 발행했으며; 중간, 고위험, 미확인 위험이 인증 OTP를 보냈고, 반복적인 실패 챌린지가 고정된 임계값까지 도달해 9개 브랜드 모두에서 공유 계정이 차단되었습니다. 계정 자체가 비밀번호 설정과 이메일 변경을 노출했는데, 주요 이메일 변경으로 인해 이전 소셜 제공업체가 연동이 해제되고 제공업체 재인증이 필요했습니다. 제공업체 서비스 실패가 부분 상태를 생성하지 않아: 안전한 오류를 반환하고 재시도하여 같은 오케스트레이터로 라우팅되었기 때문에, 실패한 Apple이나 Google 통화는 반쯤 연결되거나 중복된 계정을 생성하지 않았습니다. 연결 경계는 검증된 제공자 응답, 호환되는 동일 이메일 매칭, 성공적인 이메일 코드 챌린지의 세 가지 체크를 결합했으며, 실패한 코드 제출은 위험 OTP와 동일한 챌린지 제어 및 차단 정책을 거쳤습니다.