Dziękujemy za zainteresowanie konferencją Google I/O. Oglądanie treści na żądanie.

Jak adidas przyspieszył wdrażanie kluczy dostępu i zwiększył ich niezawodność dzięki funkcji Conditional Create i interfejsowi Signal API

Christopher Kokott

Yu Tsuno

Organizacje i deweloperzy napotykają poważną przeszkodę podczas przenoszenia użytkowników z haseł na klucze dostępu. Kody dostępu zapewniają istotne ulepszenie zabezpieczeń, ale proces ich ręcznego tworzenia może być uciążliwy. W środowisku e-commerce o dużej liczbie transakcji każda sekunda wahania ma znaczenie, ponieważ każde opóźnienie może potencjalnie zakłócić ścieżkę zakupu i doprowadzić do porzucenia koszyka. Ponadto synchronizowanie stanów danych logowania między serwerem a urządzeniem użytkownika jest niezbędne, aby zapobiegać błędom logowania i frustracji użytkowników.

Firma adidas zmagała się z tymi samymi problemami. Ich głównym celem było wyeliminowanie utrudnień w procesie logowania i uproszczenie korzystania z usług na platformach internetowych i w aplikacjach oraz na różnych urządzeniach. Chociaż bezpieczeństwo pozostaje dla nas priorytetem, zespół produktu skupił się na tym, aby procesy rejestracji i logowania za pomocą kluczy dostępu były jak najprostsze.

Aby rozwiązać te problemy, firma adidas wdrożyła Conditional Create, które automatycznie przekształca hasła użytkowników w klucze dostępu, oraz Signal API, które zapewnia spójność danych logowania. Dodatkowo wdrożyli żądania dotyczące powiązanych źródeł, aby w razie potrzeby obsługiwać użycie w wielu domenach.

Wyniki

Strategia adidas polegająca na automatyzacji tworzenia kluczy dostępu i dbaniu o bezpieczeństwo danych logowania przyniosła natychmiastowe, wymierne rezultaty zarówno pod względem wdrożenia, jak i niezawodności logowania:

Wysoki wskaźnik rozpowszechnienia: od wprowadzenia procesu logowania za pomocą klucza dostępu firma adidas osiągnęła ogólny wskaźnik tworzenia kluczy dostępu na poziomie 47%. Obejmuje to zarówno automatyczne tworzenie warunkowe, jak i zgody użytkowników inicjowane na prośbę podczas rejestracji lub logowania. Wskaźnik ten był szczególnie wysoki na urządzeniach mobilnych, na których wyniósł 52% (w porównaniu z 34% na komputerach).
Przyspieszone uaktualnienia za pomocą warunkowego tworzenia: oprócz wyraźnych zachęt firma adidas osiągnęła 8-procentowy wzrost liczby utworzonych kluczy dostępu dzięki płynnemu uaktualnianiu istniejących haseł użytkowników w tle bez konieczności podejmowania przez nich ręcznych działań.
Niemal idealna niezawodność logowania: klucze dostępu zapewniają ponad 99% skuteczności po rozpoczęciu logowania. To duża poprawa bezpieczeństwa w porównaniu z historycznym odsetkiem prawidłowych haseł w przypadku adidas, który wynosił 70% i często był obniżany przez błędy ludzkie, takie jak literówki czy zapomniane dane logowania.
Zminimalizowanie problemów i błędów: dzięki wdrożeniu interfejsu Signal API do automatycznej synchronizacji danych logowania na urządzeniu i serwerze firma adidas zdołała ograniczyć liczbę błędów do mniej niż 0, 3% prób logowania.PASSKEY_NOT_FOUND Dzięki temu użytkownicy nie będą już sfrustrowani osieroconymi kluczami dostępu.

47 _%

Szybkość tworzenia kluczy dostępu

8 _%

Wzrost liczby utworzonych kluczy dostępu przy użyciu warunkowego tworzenia

>99 _%

Wskaźnik sukcesu logowania za pomocą klucza dostępu po zainicjowaniu

<0,3 _%

Odsetek błędów związanych z osieroconymi kluczami dostępu

Jak adidas rozwiązał ten problem

Oto jak firma adidas poradziła sobie z tymi wyzwaniami:

1. Szybsze wdrażanie dzięki tworzeniu warunkowemu

Aby ułatwić użytkownikom przejście na klucze dostępu, firma adidas wdrożyła warunkowe tworzenie. Ta funkcja umożliwia witrynie automatyczne utworzenie klucza dostępu, gdy użytkownik loguje się za pomocą hasła zapisanego w menedżerze haseł. Aby zapewnić jak największą skuteczność, system wywołuje interfejs API natychmiast po zalogowaniu się użytkownika, dzięki czemu system rozpoznaje użycie hasła jako niedawne.

const cred = await navigator.credentials.create({
  publicKey: options,
  mediation: 'conditional' // Enables automatic passkey creation
});

Firma adidas zintegrowała tę funkcję z niestandardową logiką, która najpierw weryfikuje środowisko użytkownika. System sprawdza w szczególności, czy przeglądarka obsługuje funkcję tworzenia warunkowego. System uwzględnia też preferencje użytkownika, ponieważ nie wyświetla prośby, jeśli w ciągu ostatnich 6 miesięcy użytkownik 3 razy pominął tworzenie klucza dostępu.

Jeśli środowisko jest zgodne, system próbuje utworzyć klucz dostępu w tle natychmiast po pomyślnym uwierzytelnieniu użytkownika. Ten konkretny moment zwiększa prawdopodobieństwo spełnienia wymagań wstępnych. Ważne jest to, że implementacja obsługuje wyjątki WebAuthn zgodnie z zasadą „fail-open”, aby zawsze priorytetowo traktować dostęp użytkownika. Jeśli przeglądarka zgłosi InvalidStateError, co oznacza, że klucz dostępu prawdopodobnie już istnieje, system zatrzyma tworzenie w tle i natychmiast zaloguje użytkownika. Jeśli wystąpi NotAllowedError, co oznacza, że nie zostały spełnione określone warunki automatycznego tworzenia, system wykryje ten stan i przekieruje użytkownika na ekran „Kolektor kluczy dostępu”, aby przeprowadzić go przez proces konfiguracji ręcznej. Dzięki rozróżnieniu tych ograniczeń technicznych i zachowań użytkowników firma adidas ma pewność, że zachęcanie do uaktualnienia do kluczy dostępu poprawia proces logowania, a nie go przerywa.

Na stronie adidas pojawia się komunikat „Następnym razem zaloguj się za pomocą klucza dostępu”, który zachęca użytkowników do utworzenia klucza dostępu, aby logować się szybciej i bezpieczniej przy użyciu danych biometrycznych lub kodu dostępu. — Ekran „Kolekcja kluczy dostępu”.

2. Zapewnianie niezawodności za pomocą interfejsu Signal API

Gdy użytkownicy zarządzają danymi logowania na różnych urządzeniach, mogą pojawiać się niespójności. Na przykład klucz dostępu może zostać usunięty z serwera, ale nadal będzie dostępny na urządzeniu użytkownika. Aby zapobiec nieudanym próbom logowania spowodowanym przez te „fantomy”, firma adidas wdrożyła interfejs Signal API. Ten interfejs API umożliwia serwerowi sygnalizowanie stanu danych logowania dostawcy kluczy dostępu.

Aby zachować tę spójność, adidas korzysta ze wszystkich 3 dostępnych metod interfejsu Signal API. Zamiast zgadywać, które dane logowania usunąć, adidas przypisuje konkretne zdarzenia z cyklu życia użytkownika do odpowiedniego wywołania interfejsu API:

Nieudane rejestracje: gdy klucz dostępu zostanie utworzony na urządzeniu klienta, ale nie uda się go zarejestrować na serwerze backendu, adidas używa signalUnknownCredential, aby natychmiast usunąć osierocone dane logowania.
Nieprawidłowe logowania: jeśli użytkownik spróbuje zalogować się za pomocą unieważnionego lub nieaktualnego klucza dostępu, signalUnknownCredential wysyła do dostawcy sygnał, aby go ukryć.
Zarządzanie użytkownikami: gdy użytkownik wyraźnie usunie klucz dostępu w ustawieniach konta, signalAllAcceptedCredentials zsynchronizuje listę dozwolonych. Dzięki temu usunięty klucz dostępu nie będzie już oferowany.
Aktualizacje konta: gdy użytkownik zmieni adres e-mail lub nazwę użytkownika,signalCurrentUserDetails aktualizuje metadane na urządzeniu, aby były zgodne z serwerem.

// Detect authentication failure due to lack of the credential

if (result.status === 404) {
  if (PublicKeyCredential.signalUnknownCredential) {
    await PublicKeyCredential.signalUnknownCredential({
      rpId: "adidas.com",
      credentialId: "..." // base64url encoded credential ID
    });
  }
}

Okno modalne potwierdzenia w ustawieniach konta adidas, które umożliwia użytkownikowi usunięcie konkretnego klucza dostępu, z ostrzeżeniem, że nie będzie on już dostępny do logowania. — Okno modalne potwierdzenia usunięcia klucza dostępu.

Powiadomienie z Menedżera haseł Google informujące o usuniętym kluczu dostępu, który już nie działa. Pokazuje, jak interfejs Signal API synchronizuje urządzenie użytkownika z serwerem. — Powiadomienie interfejsu Signal API o usuniętym kluczu dostępu.

3. Ujednolicenie dostępu za pomocą powiązanych żądań dotyczących źródła i Digital Asset Links

Aby jeszcze bardziej usprawnić architekturę wielorynkową, firma adidas wdrożyła żądania dotyczące powiązanych domen. Większość użytkowników korzysta z rynku lokalnego (np. adidas.nl), ale ta konfiguracja umożliwia użytkownikom, którzy poruszają się między regionami, ponowne używanie kluczy dostępu w dozwolonych domenach przez kierowanie na jeden identyfikator podmiotu ufającego (adidas.com).

Aby to umożliwić, firma adidas hostuje plik konfiguracyjny webauthn w swojej domenie głównego identyfikatora podmiotu ufającego (RP ID). Ten plik zawiera jawną listę dozwolonych domen, które mogą używać funkcji adidas.com do rejestracji i uwierzytelniania za pomocą klucza dostępu. Określając te relacje, przeglądarka może sprawdzić, czy klucz dostępu utworzony w jednej witrynie regionalnej jest ważny w innej, co zapewnia użytkownikom na całym świecie bezproblemowe korzystanie z usług.

// https://www.adidas.com/.well-known/webauthn

{
  "origins": [
    "https://www.adidas.fi",
    "https://www.adidas.nl",
    // ... abridged (the full file lists 50+ regional domains)
  ]
}

Co ważne, firma adidas zapewniła też bezproblemową obsługę kluczy dostępu w swoich aplikacjach mobilnych na Androida za pomocą Digital Asset Links. Aplikacje używają do uwierzytelniania komponentu WebView hostowanego na stronie idp.adidas.com, dlatego do nawiązania zaufanej relacji między aplikacją na Androida a identyfikatorem Relying Party (adidas.com) wymagane były linki Digital Asset Links. Ta weryfikacja umożliwia aplikacji dostęp do tych samych kluczy dostępu, które są używane w internecie, co zapewnia płynne i ujednolicone logowanie na różnych platformach.

W tym celu adidas przechowuje plik Digital Asset Links (assetlinks.json) w odpowiednich domenach internetowych. Ten plik publicznie deklaruje powiązanie kryptograficzne z aplikacjami na Androida. Podobnie, aby obsługiwać ekosystem iOS, adidas używa powiązanych domen. Hostując plik apple-app-site-association, nawiązują bezpieczne połączenie, które umożliwia aplikacji na iOS bezpieczne korzystanie z kluczy dostępu w widoku internetowym.

// https://www.adidas.fi/.well-known/assetlinks.json

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.adidas.app",
      "sha256_cert_fingerprints": [
        "B2:55:43:78:89:F6:F6:FD:BB:16:5C:43:EE:66:14:18:D4:E8:33:6D:3A:1F:68:86:C3:A8:7C:89:2B:51:45:96",
        "..."
      ]
    }
  },
  // ... abridged
]

Diagram techniczny przedstawiający relacje zaufania ustanowione za pomocą żądań dotyczących powiązanych domen (ROR) i Digital Asset Links (DAL) między urządzeniem klienta a serwerem docelowym. — Schemat sekwencji powiązanych żądań dotyczących źródła

Prośba o użycie klucza dostępu na poziomie systemu na urządzeniu z Androidem, w której użytkownik jest proszony o użycie zapisanego klucza dostępu do zalogowania się u dostawcy tożsamości adidas. — Logowanie warunkowe

Ekran logowania w aplikacji mobilnej adidas z przyciskiem „Kontynuuj za pomocą klucza dostępu”, który usprawnia proces uwierzytelniania. — Najpierw identyfikator

Co dalej z adidasem?

Dzięki solidnym podstawom w postaci automatycznych aktualizacji i zsynchronizowanych danych logowania na stronach adidas.fi i adidas.nl firma adidas wdroży to bezproblemowe rozwiązanie na wszystkich pozostałych rynkach globalnych do końca kwietnia 2026 r. adidas testuje też natychmiastowe zapośredniczenie, aby zapewnić jeszcze łatwiejsze logowanie. W przyszłości planujemy umożliwić użytkownikom tworzenie kont bezpośrednio za pomocą kluczy dostępu. Dzięki temu nie trzeba już rejestrować się za pomocą alternatywnej metody. Zespół bada też „inteligentne wyzwalanie”, aby bezpośrednio wywoływać okno dialogowe klucza dostępu do systemu w drugim etapie logowania. Eliminuje to konieczność dodatkowego kliknięcia, gdy istnieje duże prawdopodobieństwo, że użytkownik ma klucz dostępu dostępny na bieżącym urządzeniu.

Dlaczego jest to ważne

Przejście na uwierzytelnianie bez hasła powiedzie się, jeśli środowisko użytkownika pozostanie bezproblemowe. Dzięki wdrożeniu warunkowego tworzenia możesz łatwo przenieść użytkowników z haseł bez zakłócania ich przyzwyczajeń. Korzystając z funkcji Related Origin Requests (Prośby dotyczące powiązanych źródeł), możesz udostępniać klucze dostępu w swoich domenach, dzięki czemu użytkownicy będą mogli bezproblemowo uzyskiwać dostęp do całego ekosystemu za pomocą jednego klucza dostępu. Połączenie tej funkcji z interfejsem Signal API zapewnia niezawodność i bezbłędność ujednoliconego środowiska bez haseł.

Jak adidas przyspieszył wdrażanie kluczy dostępu i zwiększył ich niezawodność dzięki funkcji Conditional Create i interfejsowi Signal API Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.