01 Kontekst i problem
Grupa konsumencka prowadziła dziewięć oddzielnych marek na jednej wspólnej platformie klienta. Klient może założyć konto raz i używać go wszędzie, logując się przez Apple, Google lub e-mail i hasło. Logowanie społeczne miało być głównym sposobem wejścia, a nie dodatkową wygodą, więc ta sama osoba często pojawiała się przez różnych dostawców o różnych porach: Google na jednej marce, Apple na innej, a hasło później.
Ta elastyczność stworzyła problem z tożsamością. Gdy klient logował się za pomocą nowej tożsamości Apple lub Google, którego e-mail już należał do istniejącego konta, platforma musiała zdecydować, co zrobić. Automatyczne połączenie tych dwóch stron tylko na podstawie dopasowania e-mailowego byłoby niebezpieczne: dopasowany adres e-mail sugeruje relację, ale nie dowodzi, że osoba logująca faktycznie kontroluje tę skrzynkę odbiorczą. Platforma potrzebowała sposobu na połączenie kompatybilnych tożsamości Apple i Google z jednym współdzielonym kontem bez samodzielnego przyznawania dostępu do e-maili, i to konsekwentnie we wszystkich dziewięciu markach, w tym w niewygodnych przypadkach: prywatnych adresach przekaźników Apple, kontach z hasłem, ryzykownych logowaniach i przerwach w dostawcach.
02 Rola i ograniczenia
Jako AI Product Manager byłem właścicielem projektu łączenia tożsamości i kont od początku do końca: ścieżki uwierzytelniania we wszystkich dziewięciu markach, logikę wykrywania i rozwiązywania tych samych e-maili, model weryfikacji blokujący linkowanie, politykę wyzwań opartych na ryzyku, obsługę prywatnych relayów, zasady odłączania i ponownej weryfikacji przy zmianie e-maili, politykę blokowania oraz zachowanie bezpiecznej awarii w przypadku przerw dostawców. Zasadą przewodnią było to, że dopasowanie e-mailowe mogło rozpocząć proces linkowania, ale nigdy go nie zakończyć. Klient zawsze musiał wykazać dostęp do e-maila powiązanego z istniejącym kontem, zanim do jednego profilu przypisano dwa sposoby uwierzytelniania.
Ograniczenia były konkretne. Linkowanie musiało być dwukierunkowe i niezależne od kolejności: najpierw Google, potem Apple, albo Apple najpierw, a potem Google, musiało dotrzeć do tego samego wspólnego konta. Funkcja Ukryj mój e-mail Apple musiała być obsługiwana osobno, ponieważ prywatny adres relay, który nie pasował do prawdziwego konta klienta, nie może bezgłośnie łączyć się z tym kontem. Weryfikacja musiała ponownie wykorzystać ten sam mechanizm wyzwań kodowych, który już wcześniej ufał do uwierzytelniania o podwyższonym ryzyku, więc wiązać odziedziczone sprawdzone kontrole, zamiast wymyślać nowe. Ryzyko musiało modulować tarcie: zgłoszenia o niskim ryzyku powinny pozostać beztarcia, podczas gdy ryzyko średnie, wysokie i nieokreślone wymagały OTP. Powtarzające się niepowodzenia musiały być ograniczane przez politykę blokującą obowiązującą na poziomie konta, dla każdej marki, a nie dla każdej marki. A awarie dostawcy musiały być bezpieczne, nigdy nie pozostawiając klienta z częściowym lub podwójnym kontem.
Podejście produktowe 03
Główna zmiana miała na celu traktowanie dopasowania e-maila jako początku procesu weryfikacji, a nie jako dowodu własności. Gdy Apple lub Google uwierzytelniały klienta, odpowiedź dostawcy oraz jego e-mail były rozwiązywane po stronie serwera na platformie współtworzonego konta. Jeśli e-mail pasował do istniejącego konta, platforma jeszcze nic nie podlinkowała. Wydano jednorazowy kod na adres e-mail na istniejącym koncie i połączyło nowego dostawcę dopiero po wpisaniu tego kodu przez klienta. Dwie metody uwierzytelniania zostały przypisane do jednego profilu międzymarkowego dopiero po wykazaniu własności.
Ta sama zweryfikowana ścieżka obejmowała oba kierunki łączące. Jeśli klient założył konto w Google i później wybrał Kontynuuj z Apple używając tego samego wspólnego e-maila, system wykrywał istniejące konto, wysyłał kod na jego adres e-mail i łączył Apple po pomyślnej weryfikacji. Odwrotnie, najpierw Apple udostępnił mój e-mail, a potem Google, rozwiązało to samo wspólne konto w tym samym wyzwaniu. Po połączeniu klient mógł zalogować się przez Apple, Google lub za pomocą e-maila i hasła, niezależnie od tego, gdzie zostało skonfigurowane, i trafić na to samo konto.
Ukryj mój e-mail od Apple pozostawał celowo oddzielną ścieżką. Gdy adres prywatnego przekaźnika nie zgadzał się z nieujawnionym adresem prywatnym klienta, tożsamości nie kwalifikowały się do linkowania na ten sam adres e-mail. Zamiast łączyć przekaźnik z niepowiązanym kontem, platforma pokazała wyjaśnienie ograniczonego dostępu i utworzyła osobne konto e-mail dla przekaźnika. Poza pierwszym połączeniem, to samo konto miało własny cykl życia: klient mógł ustawić hasło do konta społecznościowego, zmienić główny adres e-mail (co odłączyło poprzedniego dostawcę i wymagało ponownej weryfikacji), a każde powracające logowanie przechodziło przez ocenę ryzyka przed uruchomieniem sesji.
Pasujący e-mail wygląda jak dowód tożsamości, ale jest tylko sygnałem. Platforma wykorzystała go do otwarcia ścieżki weryfikacji, nigdy nie do udzielenia dostępu. Kompatybilne tożsamości Apple i Google były powiązane z jednym współdzielonym kontem dopiero po ukończeniu przez klienta wyzwania kodu e-mailowego, więc dopasowanie inicjowało weryfikację zamiast automatycznie łączyć dwa loginy.
04 Zbudowane cechy
Logowanie Apple i Google
Jeden z aranżatorów uwierzytelniania kieruje zasady Continue with Apple, Continue with Google oraz logowanie hasłem na wszystkie dziewięć marek.
Wspólne konto międzymarkowe
Klient zakłada konto raz i używa go ponownie u każdej marki, niezależnie od tego, przez którego dostawcę trafi.
Wykrywanie tej samej wiadomości elektronicznej
Rozwiązywanie tożsamości po stronie serwera sygnalizuje, gdy e-mail nowego dostawcy należy już do istniejącego konta.
Wyzwanie kodu e-mailowego
Jednorazowy kod wysłany na adres e-mail istniejącego konta musi zostać wprowadzony przed połączeniem dwóch dostawców.
Łączenie dwukierunkowe
Google najpierw Apple, albo Apple najpierw Google, a potem Google, decydują się na to samo wspólne konto przez to samo wyzwanie.
Ścieżka prywatnego przekaźnika Apple
Ukryj moje adresy e-mail, które się nie zgadzają, nie są powiązane; zamiast tego tworzone jest osobne konto e-mail przekaźnikowy.
OTP oparte na ryzyku
Osoby o niskim ryzyku dostają sesję; Ryzyko średnie, wysokie i nieokreślone wymagają przesłania e-maila OTP przed uzyskaniem dostępu.
Blokowanie na poziomie konta
Powtarzające się błędy OTP, kodu lub haseł blokują wspólne konto na wszystkich dziewięciu interfejsach marki.
Konfiguracja haseł do społeczności społecznościowej
Klienci mogą dodać e-mail i hasło do konta utworzonego przez dostawcę mediów społecznościowych.
Rozdzielanie dostawcy po zmianie poczty elektronicznej
Zmiana głównego adresu e-mail łączy poprzedniego dostawcę społecznościowego i wymaga ponownej weryfikacji operatora.
Bezpieczne odzyskiwanie po awarii dostawcy
Awarie usług Apple lub Google zwracają bezpieczny błąd i próbę ponowną, zapobiegając częściowemu lub duplikatowi kont.
Hasło + parzytet społeczny
Po skonfigurowaniu hasła e-mail i hasło działają równolegle z Apple i Google jako równorzędne logowanie.
Dodano również: ustawienie hasła do kont społecznościowych, e-mail i dodatkowe logowanie po skonfigurowaniu, zmiany e-maila z hasłem, ponowna weryfikacja dostawcy po zmianie maila, zarządzanie ryzykiem nieokreślonym oraz spójna ścieżka bezpieczeństwa niezależnie od marki, od której klient zaczynał.
Architektura 05
Dziewięć doświadczeń z marką zaowocowało jednym orkesterem uwierzytelniania. Klient przyjeżdżający przez dowolną markę był kierowany do tego samego procesu: kontynuuj z Apple, kontynuuj z Google lub e-mail i hasło. Odpowiedzi Apple i Google przechodziły weryfikację odpowiedzi dostawcy, a następnie rozwiązanie tożsamości na platformie współdzielonego konta, podczas gdy logowania hasłem rozwiązywały się bezpośrednio na wspólne konto. Identity Resolution zadała dwa pytania kolejno: czy ten dostawca jest już powiązany, a jeśli nie, czy istnieje odpowiednie konto e-mail o tym samym koncie, do którego można się połączyć.
Stamtąd przepływ rozgałęział się w wyraźnie określone wyniki. Uprawniony e-mail wydawał kod łączący adres e-mail istniejącego konta; Po pomyślnej weryfikacji dostawca był łączony, a w przypadku niepowodzenia próba była odrzucana i nagrywana. E-mail przekazany przez Apple, który nie pasował, został przekierowany na wyjaśnienie ograniczonego dostępu i osobne konto e-mail przekazujący. Po rozwiązaniu konta na wspólne konto międzymarkowe, status konta był sprawdzany: zablokowane konto było oznaczone jako zablokowane, aktywne konto zaliczane do kategorii ryzyka. Niskie ryzyko wydawało sesję uwierzytelnioną bezpośrednio; Średnie, wysokie i nieokreślone ryzyko wysłało OTP do uwierzytelniania, a powtarzające się nieudane wyzwania, do stałego progu, zablokowały wspólne konto we wszystkich dziewięciu markach. Samo konto ujawniało zmiany ustawień haseł i e-mail, gdzie zmiana głównego adresu e-mail łączyła poprzedniego dostawcę społecznościowego i wymagała ponownej weryfikacji przez dostawcę. Awarie usług dostawców nie powodowały częściowego stanu: zwracały bezpieczny błąd i próbę ponowną, która była kierowana z powrotem do tego samego orkiestratora, więc nieudane połączenie Apple lub Google nigdy nie wygenerowało konta, które było częściowo połączone lub duplikowane. Granica linkowania łączyła trzy kontrole: zweryfikowaną odpowiedź dostawcy, kompatybilne dopasowanie tej samej wiadomości e-mail oraz pomyślne wyzwanie kodu e-mailowego, a nieudane zgłoszenia kodu przechodziły przez tę samą politykę kontroli i blokowania jak OTP ryzyka.
06 Pomiary i Analityka
Ścieżki tożsamości były mierzone jako lejek od uwierzytelniania dostawcy przez rozwiązanie problemów, weryfikację i wydanie sesji, dzięki czemu można było prześledzić spadek do etapu, który go spowodował: reakcja dostawcy, wykrycie tej samej wiadomości e-mail, wyzwanie kodowe, ocena ryzyka lub blokowanie. Dostępne dane potwierdzały łączną adopcję około czterdziestu tysięcy lub stu tysięcy dziennie odwiedzających na markę korzystającą z Apple, Google lub powiązanej z kontem, ale celowo nie przeceniały tego, czego nie udało się oddzielić. Apple kontra Google, rejestracja kontra powrót do logowania, nowo powiązane konta kontra wcześniej powiązane, skuteczne kontra porzucone wyzwania kodowe, konta Apple z przekazem e-mail kontra współdzielony e-mail oraz wszelkie ograniczenia liczby duplikatów kont, oszustw lub kontaktów ze wsparciem pozostały nieoszacowane, dopóki nie pojawiły się ich podstawowe dane, zamiast przedstawiać je jako precyzyjne dane.
Metryki adopcji
Udział dziennych odwiedzających na markę korzystający z podróży Apple, Google lub linked-account, zagregowany przez dziewięć marek.
Lejek weryfikacyjny
Odpowiedź dostawcy, wykrycie tego samego e-maila, wysłany kod, zweryfikowany kod i powiązany z dostawcą, mierzone krok po kroku.
Wskaźniki ryzyka i OTP
Rozkład według kategorii ryzyka, wskaźniki wyzwania OTP dla średniego, wysokiego i nieokreślonego ryzyka oraz sukces i porzucenie OTP.
Metryki niepowodzenia i blokowania
Nieudane kody łączące, ryzykowne OTP i hasła były liczone do stałego progu i zastosowanych bloków na poziomie konta.
Metryki dostawcy i przekaźnika
Konta Apple z przekazem przekazującym kontra współdzielone e-maile oraz awarie usług operatora przekierowane do bezpiecznej próby.
07 Weryfikacja i podejmowanie decyzji dotyczących ryzyka
Warstwa decyzyjna odpowiadała na ciąg wąskich pytań, a nie na jedno "tak" lub nie. Czy ten dostawca jest już powiązany? Jeśli nie, czy istnieje kwalifikowane konto e-mail o tym samym e-mailu, czy to jest adres Apple relay, który nie jest uprawniony? Jeśli kwalifikujesz się, czy klient udowodnił własność poprzez wyzwanie kodu e-mailowego? A przy każdym rozwiązanym zalogowaniu, jaka jest kategoria ryzyka konta i czy wymaga to OTP przed wydaniem sesji? Niskie ryzyko trwało do sesji uwierzytelnionej; średnie, wysokie i nieokreślone ryzyko wymagało wysłania OTP przez e-mail; a powtarzające się niepowodzenia, czy to dotyczące kodu linkującego, ryzyka OTP czy hasła, były liczone przez jeden wspólny mechanizm kontroli wyzwań, który blokował konto na stałym progu. Ryzyko tutaj modulowane tarcie i siła weryfikacji; Nie decydował sam o tożsamości i nigdy nie zastąpił dowodu własności, który blokował łączenie.
Łączenie kont było chronione przez wyzwanie kodowe, a nie przez dopasowanie e-mailowe. Granica łączyła zweryfikowaną odpowiedź Apple lub Google, kompatybilne konto e-mail z tym samym e-mailem oraz pomyślną weryfikację e-mail. Pasujący e-mail otworzył podróż; Klient musiał jeszcze udowodnić dostęp do e-maila na istniejącym koncie, zanim do jednego profilu międzymarkowego zostały przypisane dwa logowania.
08 Status i Wyniki
Implementacja ustanowiła uwierzytelnianie społeczne jako główny kanał dostępu, a nie jako dodatkową opcję logowania. Klienci mogli zarejestrować się w Apple lub Google, ponownie używać tego samego konta we wszystkich dziewięciu markach, powiązać kompatybilne tożsamości Apple i Google po wyzwaniu kodu e-mailowego, dodać hasło do konta społecznościowego i przejść przez spójną ścieżkę bezpieczeństwa, niezależnie od marki, od której zaczynali. Każda marka otrzymywała około stu tysięcy odwiedzających dziennie, a około czterdziestu tysięcy na markę dziennie korzystało z podróży z Apple, Google lub powiązanym kontem: szacuje się, że czterdzieści procent zaangażowania w mediach społecznościowych lub powiązanych było dostępne. We wszystkich dziewięciu markach to około dziewięćset tysięcy dziennie odwiedzających oraz około trzystu sześćdziesięciu tysięcy dziennie w społecznościach społecznościowych lub powiązanych kontach. W efekcie powstała wspólna baza uwierzytelniania, w której Apple, Google i dostęp do haseł działały jako kontrolowane metody wokół jednego konta klienta z różnych marek, z powiązaniami zablokowanymi przez weryfikację, ryzykownymi logowaniami przez OTP, prywatnym przekaźnikom obsługiwanym osobno, a powtarzającymi się niepowodzeniami ograniczanymi przez blokowanie na poziomie konta. Te wartości są przybliżone i oparte na podanym stosunku; Łączą aktywność społecznościową i powiązaną z kontami, zamiast rozdzielać każdego dostawcę czy typ podróży.
~40%
Codzienni odwiedzający korzystający z społecznościowej lub powiązanej ścieżki (dla każdej marki)
9
Marki konsumenckie na jednym wspólnym koncie
~360K
Codzienne podróże z Apple, Google lub powiązanymi kontami
~900K
Łączna liczba codziennych odwiedzających w całej grupie
09 Refleksja / Co dalej
Definiującym osiągnięciem było to, że nie dodałem przycisków Apple i Google. Tworzyła kontrolę tożsamości, która czyniła dostęp społeczny bezpiecznym i wielokrotnie użytecznym dla dziewięciu marek: platforma mogła rozpoznać, czy tożsamość dostawcy jest nowa, już połączona, kwalifikuje się do linkowania, korzysta z prywatnego przekaźnika, jest obsługiwana hasłem, ryzykowna lub zablokowana, a kompatybilne tożsamości łączyła dopiero po wyzwaniu kodu e-mail. Co chciałbym wzmocnić dalej: oddzielić analitykę, która dziś pozostaje połączona (Apple kontra Google, rejestracja vs logowanie, nowe od wcześniej powiązanych, sukces wyzwania od porzucenia, relay kontra współdzielony e-mail), tak aby lejek mógł być dostrojony dowodami, a nie szacunkami; sformalizować definicje kategorii i progi modelu ryzyka z wyraźnym zarządzaniem; Zaostrzenie wytycznych dotyczących kont przekaźnikowych, aby klienci rozumieli, dlaczego logowanie Ukryj mój e-mail stworzyło osobne konto; oraz zachowanie reguł odłączania i ponownej weryfikacji zmian e-maili audytowalnymi od początku do końca. Trwałym efektem była wspólna warstwa uwierzytelniania, gdzie dopasowany e-mail inicjował weryfikację, a nie automatycznie przyznawał dostęp, a logowania Apple, Google i haseł działały jako kontrolowane, powiązane metody wokół jednego konta klienta z różnych marek.