Bezproblemowe i prywatne uwierzytelnianie użytkowników za pomocą FedCM: podejście Seznamu

Natalia Markoborodova

Opublikowano: 8 września 2025 r.

Liderzy branży w wielu sektorach rozumieją, jak ważne jest zapewnienie ochrony prywatności przy jednoczesnym dbaniu o wysoki komfort użytkowników. Firma Seznam dba o zapewnienie użytkownikom jak najlepszych wrażeń i ochrony prywatności. Z sukcesem wdrożyła sfederowane zarządzanie danymi logowania (FedCM).

Firmy, które mogą odnieść korzyści z FedCM

Organizacje z różnych branż integrują FedCM ze swoimi rozwiązaniami. FedCM jest przeznaczony do zarządzania tożsamościami sfederowanymi, dlatego głównymi beneficjentami tej funkcji są dostawcy tożsamości. Używają go, aby zapewnić lepsze wrażenia podczas 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ż dostrzegają możliwości ulepszenia obsługi użytkowników dzięki 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 znaczny 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ł zaprojektowany 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ć 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 zapewnia ochronę prywatności. Na przykład wizyta użytkownika w podmiocie ufającym jest udostępniana dostawcy tożsamości tylko wtedy, gdy użytkownik się zaloguje. Jest to zgodne z poglądem firmy Seznam na zrównoważony rozwój biznesu.

Szczegóły implementacji

Firma Seznam wdrożyła FedCM jako warstwę na istniejącym rozwiązaniu OAuth. W tej architekturze przepływ FedCM bezpiecznie przesyła kod autoryzacji OAuth od dostawcy tożsamości do podmiotów zależnych.

Nakład pracy związany z wdrożeniem

Firma Seznam uznała wdrożenie FedCM za proste i zgodne z jej dotychczasowym podejściem. Badania i wdrażanie interfejsu API trwały miesiąc i wymagały zaangażowania 2 deweloperów. Wdrożenie FedCM w środowisku produkcyjnym zajęło mniej niż 2 miesiące. Proces ten był iteracyjny i poświęcono mu dużo czasu na zapoznanie się z interfejsem 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 mogli wybierać między kontami Seznam i Google na platformach tożsamości partnerów. Gdy jednak Seznam po raz pierwszy podjął się wdrożenia FedCM, funkcja ta była na wczesnym etapie implementacji, a programiści musieli zarejestrować się w programie testów pochodzenia i użyć tokena, aby włączyć tę funkcję dla 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 od Chrome 136, a 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 RP może to zrobić niezależnie:

  // Executed on the RP's side:
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // IdP1: Seznam config file URL
            configURL: 'https://szn.cz/.well-known/web-identity',
            clientId: '123',
          },
          {
            // Allow Google Sign-in
            configURL: 'https://accounts.google.com/gsi/fedcm.json',
            clientId: '456',
          },
        ],
      },
    });

Seznam wskazuje, ż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 firma Seznam napotkała problem związany z konfiguracją sieci. Serwer dostawcy tożsamości testowej znajdował się w sieci prywatnej, do której dostęp był możliwy tylko przez prywatny DNS. Ta konfiguracja jest często stosowana w przypadku testów wewnętrznych i środowisk programistycznych przed udostępnieniem publicznym.

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 wersji produkcyjnej.
• 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żesz rozwiązać, włączając flagę Chrome #fedcm-without-well-known-enforcement. Gdy ten flag jest włączony, 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

Firma Seznam chciała też 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 – 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 kontynuacji dostawca tożsamości może przekierować użytkownika na stronę niestandardową, aby poprosić o dodatkowe informacje lub uprawnienia. Funkcje 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 pasuje do domeny, którą RP wstępnie zarejestrowała u dostawcy tożsamości. Dzięki temu żądanie potwierdzenia tożsamości FedCM pochodzi od autoryzowanej strony RP, a nie od atakującego, który używa client_id.

Seznam ma przypadek graniczny: gdy jego partnerzy RP rejestrują się w Seznamie, nie żąda on danych o pochodzeniu RP. Oznacza to, że nie można zweryfikować pochodzenia RP.

Integracja FedCM w przypadku Seznamu jest oparta na istniejącym rozwiązaniu OAuth. Zastosowano alternatywną metodę weryfikacji zarówno client_id, jak i client_secret, aby zapewnić bezpieczeństwo rozwiązania bez 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. Jej główna tożsamość korporacyjna i domena, pod którą użytkownicy powszechnie rozpoznają i darzą zaufaniem jej usługi, to seznam.cz.

W oknie FedCM wyświetla się rzeczywista domena pochodzenia punktów końcowych dostawcy tożsamości: 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 141 FedCM nie zezwala na wyświetlanie domeny innej niż ta, która hostuje implementację dostawcy tożsamości. To ograniczenie jest celowym wyborem projektowym, który ma zapewnić przejrzystość dla użytkowników. Zespół FedCM zdaje sobie jednak sprawę z trudności, jakie to ograniczenie może powodować, i dyskutuje potencjalne zmiany.

Wpływ

Dzięki interfejsowi FedCM API Seznam może teraz udostępniać użytkownikom partnerskim przepływy autoryzacji jednym kliknięciem. Podkreślono w nim zalety UX 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 tej zmiany od innych czynników. Przed integracją FedCM implementacja umożliwiała płatności jako gość z użyciem zaszyfrowanych adresów e-mail, na których użycie użytkownik wyraził zgodę, do identyfikacji użytkownika. Trudność w przeprowadzeniu takiej analizy polegała na oszacowaniu, 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ększy współczynnik konwersji mógł być spowodowany większą łatwością użycia FedCM.

Podsumowanie

Firma Seznam wdrożyła FedCM, udostępniając alternatywny proces autoryzacji obok dotychczasowego rozwiązania OAuth. Chociaż firma Seznam napotkała pewne problemy związane z obsługą dostawców tożsamości, konfiguracjami prywatnych serwerów DNS, dostosowywaniem tekstu informacji, weryfikacją punktu początkowego podmiotu ufającego i wyświetlaniem domeny użytkownikowi, interfejs API od czasu jego wdrożenia stał się bardziej zaawansowany. Zespół FedCM uwzględnił opinie Seznamu i innych pierwszych użytkowników, dzięki czemu powstały 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.