Zezwalanie na ponowne użycie klucza dostępu w witrynach w ramach powiązanych próśb o źródło

Maud Nalpas

Klucze dostępu są powiązane z konkretną witryną i można ich używać tylko do logowania się w witrynie, dla której zostały utworzone.

Jest to określone w identyfikatorze strony zależnej (RP ID), który w przypadku kluczy dostępu utworzonych dla domeny example.com może mieć postać www.example.com lub example.com.

Identyfikatory RP uniemożliwiają używanie kluczy dostępu jako pojedynczych danych logowania do uwierzytelniania w dowolnym miejscu, ale powodują problemy w przypadku:

• witryn z wieloma domenami: użytkownicy nie mogą używać tego samego klucza dostępu do logowania się w różnych domenach specyficznych dla danego kraju (np. example.com i example.co.uk) zarządzanych przez tę samą firmę;
• Domeny marki: użytkownicy nie mogą używać tych samych danych logowania w różnych domenach używanych przez jedną markę (np. acme.com i acmerewards.com);
• aplikacji mobilnych: aplikacje mobilne często nie mają własnej domeny, co utrudnia zarządzanie danymi logowania.

Istnieją obejścia oparte na federacji tożsamości i inne oparte na elementach iframe, ale w niektórych przypadkach są one niewygodne. Rozwiązaniem są żądania dotyczące powiązanych źródeł.

Rozwiązanie

Dzięki żądaniom dotyczącym powiązanych źródeł, witryna może określić źródła, które mogą używać jej identyfikatora RP.

Umożliwia to użytkownikom ponowne używanie tego samego klucza dostępu w wielu witrynach, które obsługujesz.

Aby korzystać z żądań dotyczących powiązanych źródeł, musisz udostępnić specjalny plik JSON pod określonym adresem URL https://{RP ID}/.well-known/webauthn. Jeśli example.com chce zezwolić dodatkowym źródłom na używanie go jako identyfikatora RP, powinno udostępnić ten plik pod adresem https://example.com/.well-known/webauthn:

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example-rewards.com"
  ]
}

Następnym razem, gdy któraś z tych witryn wywoła funkcję tworzenia klucza dostępu (navigator.credentials.create) lub uwierzytelniania (navigator.credentials.get), która używa example.com jako identyfikatora RP, przeglądarka zauważy, że identyfikator RP nie pasuje do źródła wysyłającego żądanie. Jeśli przeglądarka obsługuje żądania dotyczące powiązanych źródeł, najpierw wyszuka plik webauthn pod adresem https://{RP ID}/.well-known/webauthn. Jeśli plik istnieje, przeglądarka sprawdzi, czy źródło wysyłające żądanie znajduje się na liście dozwolonych allowlist. Jeśli tak, przejdzie do kroków tworzenia klucza dostępu lub uwierzytelniania.

Jeśli przeglądarka nie obsługuje żądań dotyczących powiązanych źródeł, zgłosi błąd SecurityError.

Obsługa przeglądarek

Żądania dotyczące powiązanych źródeł są obsługiwane w Chrome i Safari. W styczniu 2026 r. Firefox nadal rozważał wprowadzenie tej funkcji. Jej stan możesz śledzić w problemie dotyczącym pozycji standardów Mozilli.

Konfigurowanie żądań dotyczących powiązanych źródeł

W tej prezentacji używamy 2 witryn: https://ror-1.glitch.me i https://ror-2.glitch.me. Aby umożliwić użytkownikom logowanie się za pomocą tego samego klucza dostępu w obu tych witrynach, używamy żądań dotyczących powiązanych źródeł, aby zezwolić witrynie ror-2.glitch.me na używanie witryny ror-1.glitch.me jako identyfikatora RP.

Prezentacja

https://ror-2.glitch.me implementuje żądania dotyczące powiązanych źródeł, aby używać witryny ror-1.glitch.me jako identyfikatora RP, więc zarówno ror-1, jak i ror-2 używają witryny ror-1.glitch.me jako identyfikatora RP podczas tworzenia klucza dostępu lub uwierzytelniania za jego pomocą. Wdrożyliśmy też wspólną bazę danych kluczy dostępu w tych witrynach.

Obserwuj te działania użytkownika:

• Możesz utworzyć klucz dostępu i uwierzytelnić się za jego pomocą w witrynie ror-2, mimo że jej identyfikator RP to ror-1 (a nie ror-2).
• Gdy utworzysz klucz dostępu w witrynie ror-1 lub ror-2, możesz uwierzytelnić się za jego pomocą w obu tych witrynach.ror-1ror-2 Ponieważ witryna ror-2 określa ror-1 jako identyfikator RP, wysłanie żądania utworzenia klucza dostępu lub uwierzytelnienia z dowolnej z tych witryn jest takie samo jak wysłanie żądania z witryny ror-1. Identyfikator RP to jedyny element, który wiąże żądanie ze źródłem.
• Gdy utworzysz klucz dostępu w witrynie ror-1 lub ror-2, Chrome może automatycznie uzupełnić go w obu tych witrynach.ror-1ror-2
• Dane logowania utworzone w dowolnej z tych witryn będą miały identyfikator RP ror-1.

Zobacz kod:

• Zobacz plik /.well-known/webauthn skonfigurowany w bazie kodu ror-1.
• Zobacz wystąpienia RP_ID_ROR w bazie kodu ror-2.

Krok 1. Wdrożenie wspólnej bazy danych kont

Jeśli chcesz, aby użytkownicy mogli logować się za pomocą tego samego klucza dostępu w witrynach site-1 i site-2, wdróż bazę danych kont, która jest współdzielona przez te 2 witryny.

Krok 2. Skonfiguruj plik JSON .well-known/webauthn w witrynie site-1

Najpierw skonfiguruj witrynę site-1.com tak, aby zezwalała witrynie site-2.com na używanie jej jako identyfikatora RP. Aby to zrobić, utwórz plik JSON webauthn:

{
    "origins": [
        "https://site-2.com"
    ]
}

Obiekt JSON musi zawierać klucz o nazwie origins, którego wartością jest tablica zawierająca co najmniej 1 ciąg znaków z źródłami internetowymi.

Ważne ograniczenie: maksymalnie 5 etykiet

Każdy element tej listy zostanie przetworzony w celu wyodrębnienia etykiety eTLD + 1 label. Na przykład etykiety eTLD + 1 dla example.co.uk i example.de to example. Etykieta eTLD + 1 dla example-rewards.com to example-rewards. W Chrome maksymalna liczba etykiet to 5.

Krok 3. Udostępnij plik JSON .well-known/webauthn w witrynie site-1

Następnie udostępnij plik JSON pod adresem site-1.com/.well-known/webauthn.

Na przykład w Express:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

Używamy tu funkcji express res.json, która ustawia już prawidłowy content-type ('application/json');

Krok 4. Określ identyfikator RP w witrynie site-2

W bazie kodu site-2 ustaw site-1.com jako identyfikator RP wszędzie tam, gdzie jest to potrzebne:

• Podczas tworzenia danych logowania:
  • Ustaw site-1.com jako identyfikator RP w tworzeniu danych logowania options, które są przekazywane do navigator.credentials.create wywołania frontendowego i zwykle generowane po stronie serwera.
  • Ustaw site-1.com jako oczekiwany identyfikator RP, ponieważ przed zapisaniem danych logowania w bazie danych przeprowadzisz ich weryfikację.
• Podczas uwierzytelniania:
  • Ustaw site-1.com jako identyfikator RP w opcjach uwierzytelniania options które są przekazywane do wywołania frontendowego navigator.credentials.get i zwykle generowane po stronie serwera.
  • Ustaw site-1.com jako oczekiwany identyfikator RP, który ma zostać zweryfikowany na serwerze, ponieważ przed uwierzytelnieniem użytkownika przeprowadzisz weryfikację danych logowania.

Rozwiązywanie problemów

Inne uwagi

Udostępnianie kluczy dostępu w witrynach i aplikacjach mobilnych

Żądania dotyczące powiązanych źródeł umożliwiają użytkownikom ponowne używanie klucza dostępu w wielu witrynach. Aby umożliwić użytkownikom ponowne używanie klucza dostępu w witrynie i aplikacji mobilnej, użyj tych metod:

• W Chrome: Digital Asset Links. Więcej informacji znajdziesz w artykule Dodawanie obsługi Digital Asset Links.
• W Safari: Powiązane domeny.

Udostępnianie haseł w witrynach

Żądania dotyczące powiązanych źródeł umożliwiają użytkownikom ponowne używanie klucza dostępu w witrynach. Rozwiązania do udostępniania haseł w witrynach różnią się w zależności od menedżera haseł. W przypadku Menedżera haseł Google użyj Digital Asset Links . Safari ma inny system.

Rola menedżerów danych logowania i agentów użytkownika

Wykracza to poza Twoje kompetencje jako dewelopera witryny, ale pamiętaj, że w dłuższej perspektywie identyfikator RP nie powinien być widoczny dla użytkownika w agencie użytkownika ani w menedżerze danych logowania, z którego korzystają użytkownicy. Agenci użytkownika i menedżerowie danych logowania powinni natomiast pokazywać użytkownikom, gdzie używane są ich dane logowania. Wdrożenie tej zmiany zajmie trochę czasu. Tymczasowym rozwiązaniem może być wyświetlanie zarówno bieżącej witryny, jak i pierwotnej witryny rejestracji.