Verifierad tvåvägskoppling av konton över en identitetsplattform med nio varumärken

Den flexibiliteten skapade ett identitetsproblem. När en kund loggade in med en ny Apple- eller Google-identitet vars e-post redan tillhörde ett befintligt konto, var plattformen tvungen att bestämma vad som skulle göras. Att koppla de två automatiskt på en e-postmatchning enbart vore osäkert: en matchande e-postadress antyder en relation, men det bevisar inte att personen som loggar in faktiskt kontrollerar inkorgen. Plattformen behövde ett sätt att koppla kompatibla Apple- och Google-identiteter till ett gemensamt konto utan att någonsin ge tillgång till en e-postmatchning för sig själv, och att göra det konsekvent över alla nio varumärken, inklusive de besvärliga fallen: Apples privata reläadresser, lösenordsaktiverade konton, riskfyllda inloggningar och avbrott i leverantörer.

Begränsningarna var konkreta. Länkningen var tvungen att vara tvåvägs och ordningsoberoende: Google först och sedan Apple, eller Apple först och sedan Google, var tvungna att nå samma gemensamma konto. Apples 'Dölj min e-post' var tvungen att hanteras separat, eftersom en privat reläadress som inte stämde med kundens riktiga konto-e-post inte tyst får länkas till det kontot. Verifiering var tvungen att återanvända samma kodutmaningsmekanism som redan var betrodd för autentisering vid hög risk, så att kopplingar av ärvda beprövade kontroller istället för att uppfinna nya. Risk måste modulera friktionen: lågriskinloggningar ska förbli friktionsfria medan medel, hög och obestämd risk kräver OTP. Upprepade misslyckanden måste begränsas genom en blockeringspolicy som gällde på kontonivå, över varje varumärke, inte per varumärke. Och leverantörsfel måste vara felsäkra, så att kunden aldrig fick ett delvis eller duplicert konto.

Samma verifierade väg täckte båda länkriktningarna. Om en kund skapade ett konto hos Google och senare valde Fortsätt med Apple med samma delade e-post, upptäckte systemet det befintliga kontot, skickade en kod till sin e-post och kopplade Apple efter framgångsrik verifiering. Omvänt, Apples Dela min e-post först och Google senare, löstes till samma delade konto genom samma utmaning. Efter att ha länkat kunde kunden logga in med Apple, Google eller med e-post och lösenord där det var konfigurerat, och hamna på samma konto.

Apples Hide My Email höll sig medvetet som en separat väg. När den privata reläadressen inte stämde överens med kundens okända personliga e-postadress, var identiteterna inte berättigade för länkning av samma e-postadress. Istället för att koppla reläet till ett orelaterat konto visade plattformen en begränsad åtkomst och skapade ett separat relä-e-postkonto. Utöver första kopplingen hade samma konto sin egen livscykel: en kund kunde sätta ett lösenord på ett socialt konto, ändra primär e-postadress (vilket kopplade bort den tidigare sociala leverantören och krävde omverifiering), och varje återkommande inloggning gick ändå igenom riskutvärdering innan en session utfärdades.

Därifrån förgrenade sig flödet till tydligt avgränsade utfall. En berättigad e-postmatchning gav en länkkod till det befintliga kontots e-post; Vid framgångsrik verifiering kopplades leverantören, vid misslyckande avvisades försöket och registrerades. Ett Apple-relämejl som inte stämde överens omdirigerade till en begränsad åtkomst och ett separat relä-e-postkonto. När kontot hade blivit löst till ett delat cross-brand konto kontrollerades statusen: ett blockerat konto visades som blockerat, ett aktivt konto bedömdes i en riskkategori. Low risk utfärdade en autentiserad session direkt; medel, hög och obestämd risk skickade en autentiserings-OTP, och upprepade misslyckade utmaningar, upp till en fast tröskel, blockerade det delade kontot över alla nio varumärken. Kontot exponerade lösenordsinställning och e-poständringar, där ändring av primär e-post kopplade bort den tidigare sociala leverantören och krävde omverifiering av leverantören. Tjänstefel hos leverantörer skapade inte delstatus: de returnerade ett säkert fel och ett nytt försök som gick tillbaka till samma orkestrator, så ett misslyckat Apple- eller Google-samtal resulterade aldrig i ett halvt länkat eller duplicert konto. Länkningsgränsen kombinerade tre kontroller: ett validerat svar från leverantören, en kompatibel matchning med samma e-post och en lyckad e-postkodutmaning, och misslyckade kodinlämningar gick igenom samma utmaningskontroll- och blockeringspolicy som risk-OTP:er.