01 Kontekst og problem
En forbrukergruppe drev ni separate merker på én felles kundeplattform. En kunde kunne opprette en konto én gang og gjenbruke den overalt, logge inn med Apple, Google, eller e-post og passord. Sosial innlogging var ment å være en primær inngang, ikke en sekundær bekvemmelighet, så den samme personen kom ofte gjennom forskjellige leverandører til forskjellige tider: Google på ett merke, Apple på et annet, og et passord senere.
Den fleksibiliteten skapte et identitetsproblem. Når en kunde logget inn med en ny Apple- eller Google-identitet hvis e-post allerede tilhørte en eksisterende konto, måtte plattformen bestemme hva de skulle gjøre. Å koble de to automatisk på en e-postmatch alene ville være utrygt: en matchende e-postadresse antyder et forhold, men det beviser ikke at personen som logger inn faktisk kontrollerer innboksen. Plattformen trengte en måte å koble kompatible Apple- og Google-identiteter til én delt konto uten å noen gang gi tilgang til en e-postmatch alene, og å gjøre dette konsekvent på tvers av alle ni merkene, inkludert de vanskelige tilfellene: Apples private reléadresser, passordaktiverte kontoer, risikable pålogginger og leverandøravbrudd.
02 Rolle og begrensninger
Som AI Product Manager eide jeg identitets- og kontokoblingsdesignet fra ende til ende: autentiseringsreisene på tvers av alle ni merkevarene, logikken for deteksjon og løsning av samme e-post, verifiseringsmodellen som låste koblinger, risikobasert utfordringspolicy, håndtering av private reléer, frakoblings- og reverifiseringsreglene for e-postendring, blokkeringspolicyen og safe-fail-atferden ved leverandøravbrudd. Det ledende prinsippet var at e-postmatching kunne starte en lenkereise, men aldri fullføre den. Kunden måtte alltid vise tilgang til e-posten knyttet til den eksisterende kontoen før to autentiseringsmetoder ble koblet til én profil.
Begrensningene var konkrete. Koblingen måtte være toveis og uavhengig av rekkefølge: Google først, så Apple, eller Apple først, så Google, måtte nå den samme felles kontoen. Apples Skjul e-posten min måtte håndteres separat, fordi en privat reléadresse som ikke samsvarte med kundens ekte konto-e-post, ikke måtte kobles stille til den kontoen. Verifikasjon måtte gjenbruke den samme kodeutfordringsmekanismen som allerede var betrodd for autentisering med høy risiko, så koblingen arvet velprøvde kontroller i stedet for å finne opp nye. Risiko måtte modulere friksjonen: lavrisiko-påmeldinger skulle forbli friksjonsfriksjonsfri, mens medium, høy og ubestemt risiko krevde OTP. Gjentatte feil måtte begrenses gjennom en blokkeringspolicy som gjaldt på kontonivå, på tvers av alle merker, ikke per merkevare. Og leverandørfeil måtte være feilsikre, og aldri etterlate en kunde med en delvis eller duplisert konto.
03 Produkttilnærming
Hovedomleggingen var å behandle en e-postmatch som starten på en verifiseringsreise, ikke som bevis på eierskap. Når Apple eller Google autentiserte en kunde, ble leverandørens respons og e-post løst server-side mot plattformen for delt konto. Hvis e-posten stemte overens med en eksisterende konto, har ikke plattformen koblet noe ennå. Den utstedte en engangskode til e-posten på den eksisterende kontoen og koblet den nye leverandøren først etter at kunden hadde tastet inn koden. To autentiseringsmetoder ble koblet til én kryssmerkeprofil først når eierskap var demonstrert.
Den samme verifiserte stien dekket begge forbindelsesretningene. Hvis en kunde opprettet en konto hos Google og senere valgte Fortsett med Apple med samme delte e-post, oppdaget systemet den eksisterende kontoen, sendte en kode til e-posten sin, og koblet Apple til etter vellykket verifisering. Omvendt, Apples Del min e-post først og Google senere, ble løst til samme delte konto gjennom samme utfordring. Etter tilkoblingen kunne kunden logge inn med Apple, Google, eller med e-post og passord der det var konfigurert, og lande på samme konto.
Apples Skjul e-posten min forble en bevisst separat vei. Når den private reléadressen ikke stemte overens med kundens uoppgitte personlige e-post, var ikke identitetene kvalifisert for lenking av samme e-post. I stedet for å koble reléet til en ikke-relatert konto, viste plattformen en forklaring med begrenset tilgang og opprettet en egen relé-e-postkonto. Utover første tilknytning hadde den samme kontoen sin egen livssyklus: en kunde kunne sette passord på en sosial konto, endre primær-e-posten (som koblet fra den forrige sosiale leverandøren og krevde ny verifisering), og hver tilbakevendende innlogging gikk fortsatt gjennom risikovurdering før en økt ble utstedt.
En matchende e-post ser ut som bevis på identitet, men det er bare et signal. Plattformen brukte det til å åpne en verifiseringsreise, aldri til å gi tilgang. Kompatible Apple- og Google-identiteter ble først knyttet til én delt konto etter at kunden hadde fullført en e-postkodeutfordring, så en match startet verifisering i stedet for automatisk å slå sammen to innlogginger.
04 Bygningsfunksjoner
Apple & Google-innlogging
Én autentiseringsorkestrator ruter Continue with Apple, Continue with Google og passordpålogging på tvers av alle de ni merkevarene.
Delt kryssmerkekonto
En kunde oppretter en konto én gang og gjenbruker den på tvers av alle merker, uansett hvilken leverandør de kommer gjennom.
Deteksjon av samme e-post
Server-side identitetsoppløsning varsler når en ny leverandørs e-post allerede tilhører en eksisterende konto.
E-postkodeutfordring
En engangskode sendt til den eksisterende kontoens e-post må skrives inn før to leverandører kobles sammen.
Toveis kobling
Google-først, så Apple, eller Apple-først, så Google, løser seg til den samme delte kontoen gjennom samme utfordring.
Apple privat-relé-vei
Skjul e-postadressene mine som ikke stemmer overens, er ikke lenket; En separat relé-e-postkonto opprettes i stedet.
Risikobasert OTP
Lavrisiko-pålogginger får en økt; Middels, høy og ubestemt risiko krever en e-post-OTP før tilgang.
Blokkering på kontonivå
Gjentatte OTP-, kode- eller passordfeil blokkerer den delte kontoen på tvers av alle de ni merkegrensesnittene.
Passordoppsett for sosiale medier
Kunder kan legge til e-post og passord-innlogging på en konto som først opprettes gjennom en sosial leverandør.
Leverandørfrakobling ved e-postendring
Å endre primær-e-posten kobler fra den forrige sosiale leverandøren og krever ny verifisering av leverandøren.
Sikker gjenoppretting etter leverandørfeil
Apple- eller Google-tjenestefeil gir en sikker feil og forsøk på nytt, noe som forhindrer delvise eller dupliserte kontoer.
Passord + sosial paritet
Når et passord er konfigurert, fungerer e-post-og-passord sammen med Apple og Google som en likeverdig innlogging.
Også sendt: passordoppsett for sosiale kontoer, e-post og passord som ekstra innlogging når de er konfigurert, passordstyrte e-postendringer, ny verifisering av leverandører etter e-postbytte, håndtering av ubestemt risiko, og en konsekvent sikkerhetsreise uavhengig av hvilket merke kunden startet fra.
05 Arkitektur
Ni merkevareopplevelser matet én autentiseringsorkestrator. En kunde som kom gjennom et hvilket som helst merke, ble sendt til samme flyt: fortsett med Apple, fortsett med Google, eller e-post og passord. Apple- og Google-svar gikk gjennom validering av leverandørsvarene og deretter identitetsløsning mot plattformen for delt konto, mens passordpålogging ble løst direkte til den delte kontoen. Identity Resolution stilte to spørsmål i rekkefølge: er denne leverandøren allerede tilknyttet, og hvis ikke, finnes det en kvalifisert konto med samme e-post å koble til.
Derfra forgrenet strømmen seg til tydelig avgrensede utfall. En kvalifisert e-postmatch ga en koblingskode til den eksisterende kontoens e-post; Ved vellykket verifisering ble leverandøren koblet, ved mislykket ble forsøket avvist og registrert. En Apple-relé-e-post som ikke stemte, rutet til en forklaring med begrenset tilgang og en separat relé-e-postkonto. Når kontoen var løst til en delt kryssmerkekonto, ble statusen sjekket: en blokkert konto ble vist som blokkert, en aktiv konto ble vurdert i en risikokategori. Low Risk utstedte en autentisert økt direkte; middels, høy og ubestemt risiko sendte en autentiserings-OTP, og gjentatte mislykkede utfordringer, opp til en fast terskel, blokkerte den delte kontoen på tvers av alle ni merkene. Selve kontoen avslørte passordoppsett og e-postendringer, hvor endring av primær-e-post fjernet koblingen til den forrige sosiale leverandøren og krevde ny verifisering av leverandøren. Leverandørtjenestefeil skapte ikke delvis tilstand: de returnerte en sikker feil og et nytt forsøk som rutet tilbake til samme orkestrator, så en mislykket Apple- eller Google-samtale resulterte aldri i en halvkoblet eller duplisert konto. Koblingsgrensen kombinerte tre kontroller: en validert leverandørrespons, en kompatibel samsvar med samme e-post, og en vellykket e-postkodeutfordring, og mislykkede kodeinnsendinger gikk gjennom samme utfordringskontroll- og blokkeringspolicy som risiko-OTP-er.
06 Måling og analyse
Identitetsreisene ble målt som en trakt fra leverandørautentisering gjennom oppløsning, verifisering og utstedelse av økter, slik at et fall kunne spores til stadiet som forårsaket det: leverandørrespons, deteksjon av samme e-post, kodeutfordring, risikovurdering eller blokkering. De tilgjengelige dataene støttet et samlet estimat for adopsjon, omtrent førti tusen til hundre tusen daglige besøkende per merkevare ved bruk av en Apple-, Google- eller kontotilknyttet reise, men de overdrev bevisst ikke hva de ikke kunne skille. Apple versus Google, registrering versus tilbakevendende innlogging, nylig tilknyttede versus tidligere tilknyttede kontoer, vellykkede versus forlatte kodeutfordringer, relé-e-post versus delt e-post Apple-kontoer, og enhver reduksjon av duplikatkontoer, svindel eller støttekontakter ble ikke kvantifisert før deres underliggende analyser var tilgjengelige, i stedet for å rapporteres som presise tall.
Adopsjonsmålinger
Andel av daglige besøkende per merke som bruker en Apple-, Google- eller LinkedIn-kontoreise, aggregert på tvers av de ni merkene.
Verifikasjonstrakt
Leverandørrespons, deteksjon av samme e-post, kode sendt, kode verifisert og leverandørkobling, målt trinn for trinn.
Risiko- og OTP-målinger
Risikokategorifordeling, OTP-utfordringsrater for middels, høy og ubestemt risiko, samt OTP-suksess og -avgang.
Feil- og blokkeringsmålinger
Mislykkede koblingskoder, risiko-OTP-er og passord telte mot den faste terskelen, og kontoblokker ble pålagt.
Leverandør- og relémetrikker
Relé-e-post versus delt e-post Apple-kontoer, og feil i leverandørtjenester som ble rutet inn i sikker retry.
07 Verifisering og risikobeslutning
Beslutningslaget svarte på en rekke smale spørsmål i stedet for et enkelt ja eller nei. Er denne leverandøren allerede tilknyttet? Hvis ikke, finnes det en kvalifisert konto med samme e-post, eller er dette en Apple-reléadresse som ikke er kvalifisert? Hvis de er kvalifisert, har kunden bevist eierskap gjennom e-postkodeutfordringen? Og ved hver løst innlogging, hva er kontoens risikokategori, og krever det en OTP før en økt utstedes? Lav risiko fortsatte til en autentisert økt; middels, høy og ubestemt risiko krevde en e-post OTP; og gjentatte feil, enten på en koblingskode, en risiko-OTP eller et passord, ble telt gjennom en delt utfordringskontrollmekanisme som blokkerte kontoen ved en fast terskel. Risiko her modulerte friksjon og verifikasjonsstyrke; Den bestemte ikke identiteten alene, og erstattet aldri eierskapsbeviset som sperret koblingen.
Kontokobling var beskyttet av en kodeutfordring, ikke fullført med en e-postmatch. Grensen kombinerte et validert Apple- eller Google-svar, en kompatibel konto med samme e-post, og en vellykket e-postverifisering. En matchende e-post åpnet reisen; Kunden måtte fortsatt vise tilgang til e-posten på den eksisterende kontoen før to innlogginger ble knyttet til én kryssmerkeprofil.
08 Status og utfall
Implementeringen etablerte sosial autentisering som en hovedtilgangskanal i stedet for et sekundært innloggingsalternativ. Kunder kunne registrere seg hos Apple eller Google, gjenbruke samme konto på tvers av alle ni merkene, koble kompatible Apple- og Google-identiteter etter en e-postkodeutfordring, legge til passord på en sosial konto, og gå gjennom en konsekvent sikkerhetsreise uavhengig av hvilket merke de startet fra. Hvert merke mottok omtrent hundre tusen daglige besøkende, og omtrent førti tusen per merkevare per dag brukte en Apple-, Google- eller LinkedIn-reise: anslagsvis førti prosent engasjement med sosiale medier eller lenket tilgang. På tvers av alle ni merkene tilsvarer det omtrent ni hundre tusen daglige besøkende og rundt tre hundre og seksti tusen daglige sosiale eller tilknyttede kontoreiser. Resultatet var et felles autentiseringsfundament der Apple, Google og passordtilgang fungerte som kontrollerte metoder rundt én tverrmerke-kundekonto, med kobling styrt av verifisering, risikofylte pålogginger med OTP, privat relé håndtert separat, og gjentatte feil begrenset av kontoblokkering. Disse tallene er omtrentlige og basert på det oppgitte forholdet; De kombinerer sosial og knyttet kontoaktivitet i stedet for å skille hver leverandør eller reisetype.
~40%
Daglige besøkende som bruker en sosial eller tilkoblet reise (per merke)
9
Forbrukermerker på én felles konto
~360K
Daglige reiser med Apple, Google eller tilknyttede kontoer
~900K
Totalt antall daglige besøkende i hele gruppen
09 Refleksjon / Hva skjer videre
Den definerende prestasjonen var at de ikke la til Apple- og Google-knapper. Den bygde identitetskontrollene som gjorde sosial tilgang trygg og gjenbrukbar på tvers av ni merkevarer: plattformen kunne avgjøre om en leverandøridentitet var ny, allerede koblet, kvalifisert for kobling, ved bruk av privat relé, passordaktivert, risikabel eller blokkert, og den koblet kompatible identiteter først etter en e-postkodeutfordring. Det jeg ville styrket neste: separere analysene som i dag forblir kombinert (Apple versus Google, påmelding versus innlogging, ny versus tidligere lenket, utfordringssuksess versus forlatelse, relay versus delt e-post) slik at trakten kan tilpasses med bevis i stedet for estimater; formalisere risikomodellens kategoridefinisjoner og terskler med eksplisitt styring; stramme inn veiledningen for relékontoer slik at kundene forstår hvorfor en Skjul min e-post-pålogging opprettet en egen konto; og hold reglene for frakobling og reverifisering av e-postendringer reviderbare fra ende til ende. Det varige resultatet var et delt autentiseringslag der en matchende e-post initierte verifisering i stedet for automatisk å gi tilgang, og Apple-, Google- og passordinnlogginger fungerte som kontrollerte, lenkbare metoder rundt en enkelt tverrmerke-kundekonto.