Geverifieerde bidirectionele accountkoppeling over een identiteitsplatform met negen merken

Die flexibiliteit creëerde een identiteitsprobleem. Wanneer een klant inlogde met een nieuwe Apple- of Google-identiteit waarvan het e-mailadres al bij een bestaand account hoorde, moest het platform beslissen wat te doen. De twee automatisch koppelen op basis van een e-mailmatch zou onveilig zijn: een overeenkomend e-mailadres suggereert een relatie, maar bewijst niet dat degene die inlogt daadwerkelijk controle heeft over die inbox. Het platform had een manier nodig om compatibele Apple- en Google-identiteiten aan één gedeeld account te koppelen zonder ooit toegang te geven tot een e-mailmatch op zichzelf, en om dit consequent te doen over alle negen merken, inclusief de lastige gevallen: Apple's privé-relay-adressen, wachtwoord-actieve accounts, risicovolle aanmeldingen en uitval van providers.

De beperkingen waren concreet. Koppelen moest bidirectioneel en orderonafhankelijk zijn: eerst Google, daarna Apple, of eerst Apple en daarna Google, moesten hetzelfde gedeelde account bereiken. Apple's 'Verberg mijn e-mail' moest apart worden afgehandeld, omdat een privé-relayadres dat niet overeenkomt met het echte e-mailadres van de klant niet stilletjes aan dat account mag koppelen. Verificatie moest hetzelfde code-challenge-mechanisme hergebruiken dat al werd gebruikt voor authenticatie met verhoogd risico, dus het koppelen van geërfde bewezen controles in plaats van nieuwe te verzinnen. Risico moest wrijving moduleren: laag-risico aanmeldingen moesten wrijvingsloos blijven, terwijl medium, hoog en onbepaald risico een OTP vereiste. Herhaalde fouten moesten worden ingeperkt door een blokkeerbeleid dat op accountniveau gold, voor elk merk, niet per merk. En het falen van providers moest onveilig zijn, waardoor een klant nooit een gedeeltelijk of dubbel account had.

Hetzelfde geverifieerde pad besloeg beide verbindingsrichtingen. Als een klant een account bij Google aanmaakte en later koos voor Doorgaan met Apple met hetzelfde gedeelde e-mailadres, detecteerde het systeem het bestaande account, stuurde een code naar zijn e-mail en koppelde Apple na succesvolle verificatie. Omgekeerd werd Apple's Share My Email eerst en later Google via dezelfde uitdaging opgelost naar hetzelfde gedeelde account. Na het koppelen kon de klant inloggen bij Apple, bij Google, of met e-mail en wachtwoord waar dat ook was ingesteld, en op hetzelfde account terechtkomen.

Apple's Hide My Email bleef bewust een apart pad. Wanneer het privé-relayadres niet overeenkwam met het niet-opgegeven persoonlijke e-mailadres van de klant, kwamen de identiteiten niet in aanmerking voor koppeling van hetzelfde e-mailadres. In plaats van de relay te koppelen aan een niet-gerelateerd account, toonde het platform een uitleg met beperkte toegang en maakte een apart relay-e-mailaccount aan. Naast het eerste koppelen had hetzelfde account zijn eigen levenscyclus: een klant kon een wachtwoord instellen op een sociaal account, het primaire e-mailadres wijzigen (waardoor de vorige sociale provider werd ontkoppeld en opnieuw verifiërd moest worden), en elke terugkerende aanmelding werd nog steeds door de risico-evaluatie gehaald voordat een sessie werd afgesloten.

Van daaruit vertakte de stroom zich in duidelijk afgebakende uitkomsten. Een in aanmerking komende e-mailmatch gaf een koppelcode aan het bestaande account zijn e-mailadres; Bij succesvolle verificatie werd de provider gekoppeld, bij mislukking werd de poging afgewezen en geregistreerd. Een Apple relay-e-mail die niet overeenkwam, werd doorgestuurd naar een uitleg met beperkte toegang en een apart relay-e-mailaccount. Zodra het was opgelost naar een gedeeld cross-brand account, werd de accountstatus gecontroleerd: een geblokkeerd account werd als geblokkeerd weergegeven, een actief account werd in een risicocategorie geplaatst. Low risk voerde direct een geauthenticeerde sessie uit; Medium, High en Undetermined Risk stuurde een authenticatie-OTP, en herhaalde mislukte uitdagingen tot een vaste drempel blokkeerden het gedeelde account bij alle negen merken. Het account zelf toonde wachtwoordinstellingen en e-mailwijzigingen, waarbij het wijzigen van het primaire e-mailadres de vorige sociale provider ontkoppelde en opnieuw verificatie van de provider vereiste. Providers service failures veroorzaakten geen gedeeltelijke toestand: ze gaven een veilige foutmelding en een herpoging die terug naar dezelfde orchestrator leidde, dus een mislukte Apple- of Google-oproep leverde nooit een half gekoppeld of dubbel account op. De koppelgrens combineerde drie controles: een gevalideerde provider-reactie, een compatibele match met hetzelfde e-mailadres en een succesvolle e-mailcode-uitdaging, en mislukte code-inzendingen verliepen hetzelfde challenge-controle- en blokkeringsbeleid als risico-OTP's.