Liderzy branży w wielu sektorach rozumieją, jak ważne jest dbanie o prywatność przy jednoczesnym zapewnianiu wszystkim użytkownikom komfortu. Firma Seznam, która dba o niezakłócone wrażenia użytkowników i ich prywatność, zintegrowała interfejs Federated Credential Management (FedCM).
Profile docelowe: firmy korzystające z interfejsu FedCM
Organizacje z różnych branż zintegrowały FedCM ze swoimi rozwiązaniami. FedCM został zaprojektowany z myślą o zarządzaniu tożsamością sfederowaną, dlatego głównymi beneficjentami tej funkcji są dostawcy tożsamości, którzy mogą jej używać do zapewniania lepszego logowania. Dostawcy usług e-commerce i usług płatniczych, z których wielu pełni też rolę dostawców tożsamości, również dostrzegli możliwości poprawy komfortu użytkowników dzięki wdrożeniu FedCM.
Seznam
Seznam to europejska firma technologiczna i dostawca tożsamości, który dociera do 90% mieszkańców Czech. Jest to centrum społecznościowe, wiedzy i treści. Firma Seznam wdrożyła FedCM, aby umożliwić klientom sklepów internetowych działających na platformach jej partnerów logowanie się za pomocą konta Seznam.
Dzięki FedCM firma Seznam odnotowała zauważalny wzrost liczby logowań użytkowników w sieciach partnerów, poprawę wygody użytkowników i spójny proces identyfikacji niezależnie od dostępności plików cookie innych firm.
Motywacja
Seznam zdecydował się na wdrożenie FedCM z kilku powodów:
- FedCM zostało zaprojektowane z myślą o użytkownikach, którzy mają kontrolę nad informacjami przekazywanymi dostawcy tożsamości. Jest to zgodne z wizją firmy Seznam, która chce zapewnić swoim użytkownikom bezpieczne i prywatne środowisko.
- FedCM to wbudowana funkcja przeglądarki, która jest zgodna z dotychczasowym sposobem logowania w Seznamie, który korzysta ze standardu OAuth 2.0.
- FedCM to podejście do federacji tożsamości, które jest nastawione na ochronę prywatności. Na przykład fakt, że użytkownik odwiedził podmiot ufający, jest udostępniany dostawcy tożsamości tylko wtedy, gdy użytkownik zdecyduje się zalogować. Jest to zgodne z poglądem Seznamu na zrównoważony biznes.
Szczegóły implementacji
Firma Seznam wdrożyła FedCM jako warstwę na istniejącym rozwiązaniu OAuth. W tej architekturze przepływ FedCM jest wykorzystywany do bezpiecznego przesyłania kodu autoryzacji OAuth od dostawcy tożsamości do stron zależnych.
Nakład pracy związany z wdrożeniem
Seznam podkreślił, że wdrożenie FedCM było proste i zgodne z dotychczasowym podejściem firmy. Badania i wdrażanie interfejsu API trwały miesiąc i wymagały pracy 2 programistów. Wdrożenie FedCM w środowisku produkcyjnym zajęło im mniej niż 2 miesiące. Proces ten był iteracyjny, a dużo czasu poświęcono na dokładne zbadanie interfejsu API.
Wyzwania
Jako jeden z pierwszych użytkowników firma Seznam zidentyfikowała kilka problemów i przekazała cenne opinie, które pomogły w rozwoju interfejsu API.
Obsługa wielu dostawców tożsamości
Firma Seznam była zainteresowana obsługą wielu dostawców tożsamości przez FedCM. Dzięki tej funkcji użytkownicy mogą wybierać konta Seznam lub Google na platformach wydawców. Gdy jednak Seznam po raz pierwszy podjął się wdrożenia FedCM, funkcja była na wczesnym etapie implementacji, a deweloperzy musieli zarejestrować się w programie testów pochodzenia i użyć tokena, aby włączyć tę funkcję dla swoich użytkowników. Z tego powodu firma Seznam postanowiła poczekać, aż funkcja zostanie udostępniona w stabilnej wersji Chrome.
Ta funkcja jest dostępna w Chrome 136. Deweloperzy mogą skonfigurować obsługę wielu dostawców tożsamości. Aby na przykład obsługiwać dostawców tożsamości Seznam i Google, dostawca tożsamości może uwzględnić obu dostawców w jednym wywołaniu get(), a podmiot ufający może to zrobić niezależnie:
// Executed on the RP's side:
const credential = await navigator.credentials.get({
identity: {
providers: [
{
// IdP1: Seznam's config file URL
configURL: 'https://szn.cz/.well-known/web-identity',
clientId: '123',
},
{
// Also allow Google Sign-in
configURL: 'https://accounts.google.com/gsi/fedcm.json',
clientId: '456',
},
],
},
});
Seznam poinformował, że ta funkcja będzie częścią jego rozwiązania. Dodatkowo zespół FedCM wdraża obsługę wielu pakietów SDK, w tym obsługę wielu wywołań get().
Prywatny DNS
Podczas fazy testowania Seznam napotkał problem związany z konfiguracją sieci. Serwer dostawcy tożsamości testowego znajdował się w sieci prywatnej, do której dostęp był możliwy tylko przez prywatny DNS. Ta konfiguracja jest często stosowana w środowiskach testów wewnętrznych i programistycznych, zanim usługi zostaną udostępnione publicznie.
Ta konfiguracja wiąże się jednak z problemem: ponieważ plik well-known musi być udostępniany z domeny eTLD+1, a prywatna domena deweloperska nie jest zarejestrowana na Liście sufiksów publicznych, przeglądarka nie będzie wysyłać żądań pobrania pliku well-known hostowanego w domenie deweloperskiej:
login.idp.example: przykładowa domena produkcyjna.idp.example/.well-known/web-identity: przykładowy plik well-known w produkcji.login.dev.idp.example: przykładowa domena deweloperska.login.dev.idp.example/.well-known/web-identity: przykładowy plik well-known w środowisku deweloperskim.
Gdy implementacja FedCM jest hostowana w domenie prywatnej, żądania przeglądarki do pliku well-known
powodują ten błąd:
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
Ten błąd można rozwiązać, włączając flagę Chrome #fedcm-without-well-known-enforcement. Gdy ta flaga jest włączona, przeglądarka pomija pobieranie pliku well-known na potrzeby testowania. Dowiedz się, jak włączyć flagi testowe w Chrome.
Niestandardowe oświadczenie dotyczące informacji
Przedstawiciele Seznamu poinformowali też, że chcą dodać dodatkowe informacje do początkowego projektu interfejsu FedCM. Standardowe okno FedCM wyświetla użytkownikowi stały komunikat informujący, że określone dane – zwykle zdjęcie profilowe, imię i nazwisko oraz adres e-mail użytkownika – są udostępniane RP.
Zespół FedCM uwzględnił opinie i rozszerzył interfejs API, aby umożliwić dostosowywanie informacji wyświetlanych użytkownikowi. Na przykład dzięki funkcji kontynuowania dostawca tożsamości może przekierować użytkownika na stronę niestandardową, aby poprosić go o dodatkowe informacje lub uprawnienia. Parametry niestandardowe i pola, obsługiwane od Chrome 132, umożliwiają dalsze dostosowywanie.
Weryfikacja punktu początkowego jednostki uzależnionej
Serwer dostawcy tożsamości musi zweryfikować nagłówek HTTP Origin w przychodzącym żądaniu FedCM, aby upewnić się, że żądanie jest zgodne z domeną, którą RP wstępnie zarejestrowała u dostawcy tożsamości. Dzięki temu żądanie potwierdzenia tożsamości FedCM pochodzi od autoryzowanego dostawcy tożsamości, a nie od atakującego, który używa client_id.
Seznam ma nietypową sytuację: gdy platformy RP partnerów rejestrują się w Seznamie, nie żądają danych o pochodzeniu platformy RP. Oznacza to, że nie można zweryfikować pochodzenia RP.
Integracja FedCM w przypadku Seznamu jest oparta na istniejącym rozwiązaniu OAuth. Wybrali alternatywną ścieżkę weryfikacji zarówno client_id, jak i client_secret, aby zapewnić bezpieczeństwo rozwiązania bez konieczności sprawdzania pochodzenia.
Domena dostawcy tożsamości widoczna dla użytkownika
Infrastruktura uwierzytelniania użytkowników Seznamu działa głównie w domenie szn.cz, w której hostowane są niezbędne punkty końcowe dostawcy tożsamości dla FedCM. Ich główna tożsamość korporacyjna i domena, pod którą użytkownicy powszechnie rozpoznają i darzą zaufaniem ich usługi, to seznam.cz.
W oknie FedCM wyświetla się rzeczywista domena pochodzenia punktów końcowych dostawcy tożsamości – w tym przypadku szn.cz.
Użytkownicy znający markę seznam.cz mogą być zdezorientowani i wahać się, gdy podczas logowania pojawi się prośba o zalogowanie się w mniej znanej domenie szn.cz.
Od Chrome w wersji 141 FedCM nie zezwala na wyświetlanie domeny innej niż ta, w której hostowana jest implementacja dostawcy tożsamości. To ograniczenie jest celowym wyborem projektowym, który ma zapewnić użytkownikowi przejrzystość. Zespół FedCM zdaje sobie jednak sprawę z trudności, jakie może powodować to ograniczenie, i dyskutuje potencjalne zmiany.
Wpływ
Dzięki interfejsowi FedCM API Seznam może teraz udostępniać użytkownikom partnerów przepływy autoryzacji jednym kliknięciem. Podkreślili oni korzyści, jakie daje FedCM w porównaniu z innymi metodami uwierzytelniania.
Firma Seznam odnotowała znaczny wzrost zaangażowania użytkowników w witrynach, które przeszły na logowanie za pomocą FedCM, ale nie przeprowadziła kompleksowej analizy, aby wyodrębnić dokładny bezpośredni wpływ od innych czynników. Przed integracją FedCM implementacja umożliwiała płatności gościnne z użyciem zahaszowanych adresów e-mail, na których wykorzystanie użytkownik wyraził zgodę, do identyfikacji użytkownika. Wyzwaniem w przeprowadzeniu takiej analizy było oszacowanie, czy konwersję użytkownika można przypisać do FedCM, czy też użytkownik dokonałby zakupu za pomocą płatności bez logowania. Według hipotezy Seznamu większa łatwość użycia oferowana przez FedCM mogła przyczynić się do wyższego współczynnika konwersji.
Podsumowanie
Firma Seznam wdrożyła FedCM, zapewniając alternatywny proces autoryzacji obok istniejącego rozwiązania OAuth. Deweloperzy Seznam napotkali pewne trudności związane z obsługą dostawcy tożsamości, prywatnymi konfiguracjami DNS, dostosowywaniem tekstu informacji, weryfikacją pochodzenia podmiotu ufającego i wyświetlaniem domeny użytkownikowi, ale od czasu wdrożenia interfejs API został ulepszony. Zespół FedCM uwzględnił opinie firmy Seznam i innych pierwszych użytkowników, co pozwoliło stworzyć lepsze narzędzia do rozwiązywania tych problemów. W następnym kroku Seznam planuje wdrożyć obsługę wielu dostawców tożsamości w FedCM.