Verifizierte bidirektionale Kontoverknüpfung über eine Identitätsplattform mit neun Marken hinweg

Diese Flexibilität führte zu einem Identitätsproblem. Wenn sich ein Kunde mit einer neuen Apple- oder Google-Identität anmeldete, deren E-Mail bereits zu einem bestehenden Konto gehörte, musste die Plattform entscheiden, was zu tun war. Die beiden automatisch allein in einem E-Mail-Match zu verknüpfen, wäre unsicher: Eine übereinstimmende E-Mail-Adresse deutet auf eine Beziehung hin, beweist aber nicht, dass die Person, die sich anmeldet, tatsächlich den Posteingang kontrolliert. Die Plattform benötigte eine Möglichkeit, kompatible Apple- und Google-Identitäten mit einem gemeinsamen Konto zu verbinden, ohne jemals auf ein E-Mail-Match allein Zugriff zu gewähren, und dies konsistent über alle neun Marken hinweg zu tun, einschließlich der umständlichen Fälle: Apples private Relay-Adressen, passwortaktivierte Konten, riskante Anmeldungen und Anbieterausfälle.

Die Einschränkungen waren konkret. Die Verlinkung musste bidirektional und reihenfolgeunabhängig sein: zuerst Google, dann Apple, oder zuerst Apple, dann Google, musste dasselbe gemeinsame Konto erreichen. Apples "Hide My Email" musste separat behandelt werden, da eine private Relay-Adresse, die nicht mit der echten E-Mail des Kunden übereinstimmt, nicht stillschweigend mit diesem Konto verknüpft werden darf. Die Verifikation musste denselben Code-Challenge-Mechanismus wiederverwenden, der bereits für die Authentifizierung mit erhöhtem Risiko genutzt wurde, sodass erbeerbte, bewährte Kontrollen verknüpft wurden, anstatt neue zu erfinden. Das Risiko musste die Reibung modulieren: Niedrigrisiko-Anmeldungen sollten reibungslos bleiben, während mittleres, hohes und unbestimmtes Risiko einen OTP erforderten. Wiederholte Fehler mussten durch eine Sperrpolitik eingedämmt werden, die auf Kontoebene und nicht für jede Marke gilt. Und Anbieterausfälle mussten ausfallsicher sein, sodass der Kunde nie ein teilweises oder doppeltes Konto hatte.

Der gleiche verifizierte Weg deckte beide Verbindungsrichtungen ab. Wenn ein Kunde ein Konto bei Google erstellte und später mit derselben gemeinsamen E-Mail "Mit Apple weitermachen" wählte, erkannte das System das bestehende Konto, schickte einen Code an seine E-Mail und verknüpfte Apple nach erfolgreicher Verifizierung. Umgekehrt: Apples Share My Email zuerst und später Google wurde durch dieselbe Herausforderung auf dasselbe geteilte Konto aufgelöst. Nach der Verknüpfung konnte sich der Kunde bei Apple, bei Google oder mit E-Mail und Passwort anmelden, wo diese konfiguriert war, und auf demselben Konto landen.

Apples "Hide My Email" blieb bewusst ein separater Weg. Wenn die private Weiterleitungsadresse nicht mit der nicht genannten privaten E-Mail-Adresse des Kunden übereinstimmte, waren die Identitäten nicht für eine Verlinkung derselben E-Mail-Adresse berechtigt. Anstatt das Relay mit einem nicht verwandten Konto zu verknüpfen, zeigte die Plattform eine Erklärung mit eingeschränktem Zugriff und erstellte ein separates Relay-E-Mail-Konto. Über das erste Verknüpfen hinaus hatte dasselbe Konto seinen eigenen Lebenszyklus: Ein Kunde konnte ein Passwort für ein soziales Konto festlegen, die primäre E-Mail ändern (wodurch der vorherige soziale Anbieter entkoppelt und erneut verifiziert werden musste), und jede zurückkehrende Anmeldung wurde dennoch durch eine Risikobewertung bestanden, bevor eine Sitzung eröffnet wurde.

Von dort aus verzweigte sich der Fluss in klar begrenzte Ergebnisse. Ein berechtigter E-Mail-Match gab einen Verknüpfungscode für die bestehende Konto-E-Mail; Nach erfolgreicher Verifizierung wurde der Anbieter verknüpft, bei einem Fehlschlag wurde der Versuch abgelehnt und aufgezeichnet. Eine Apple-Relay-E-Mail, die nicht übereinstimmte, wurde zu einer Erklärung mit eingeschränktem Zugriff und einem separaten Relay-E-Mail-Konto weitergeleitet. Nachdem das Konto auf ein gemeinsames Cross-Brand Konto aufgelöst wurde, wurde der Status des Kontos überprüft: Ein gesperrtes Konto wurde als gesperrt angezeigt, ein aktives Konto wurde in eine Risikokategorie eingestuft. Low Risk hat eine authentifizierte Sitzung direkt ausgegeben; mittleres, hohes und unbestimmtes Risiko schickten ein Authentifizierungs-OTP, und wiederholte fehlgeschlagene Challenges bis zu einer festen Schwelle blockierten das gemeinsame Konto über alle neun Marken hinweg. Das Konto selbst zeigte Passworteinrichtung und E-Mail-Änderungen, wobei das Ändern der primären E-Mail den vorherigen sozialen Anbieter entkoppelte und eine erneute Verifizierung des Anbieters erforderte. Anbieter-Dienstausfälle erzeugten keinen Teilzustand: Sie lieferten einen sicheren Fehler und einen Neuanfang, der in denselben Orchestrator zurückgeleitet wurde, sodass ein fehlgeschlagener Apple- oder Google-Anruf nie ein halb verknüpftes oder doppeltes Konto erzeugte. Die Verknüpfungsgrenze kombinierte drei Kontrollen: eine validierte Anbieterantwort, eine kompatible Übereinstimmung mit derselben E-Mail und eine erfolgreiche E-Mail-Code-Herausforderung, und fehlgeschlagene Codeeinreichungen durchliefen dieselbe Challenge-Kontroll- und Blockierungsrichtlinie wie Risiko-OTPs.