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ą stroną internetową i można ich używać tylko do logowania się na stronie, dla której zostały utworzone.

Jest to określone w identyfikatorze podmiotu polegającego (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 zapobiegają używaniu kluczy dostępu jako pojedynczych danych logowania do uwierzytelniania w każdym miejscu, ale powodują problemy w przypadku:

• Witryny z wieloma domenami: użytkownicy nie mogą używać tego samego klucza dostępu do logowania się w różnych domenach krajowych (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).
• Aplikacje mobilne: 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 z 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 na wielu stronach, które obsługujesz.

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

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

Gdy następnym razem któraś z tych witryn wywoła funkcję tworzenia (navigator.credentials.create) lub uwierzytelniania (navigator.credentials.get) klucza dostępu, która używa example.com jako identyfikatora RP, przeglądarka wykryje identyfikator RP, który nie pasuje do pochodzenia żądania. Jeśli przeglądarka obsługuje żądania związane ze źródłem, najpierw szuka pliku webauthn w lokalizacji https://{RP ID}/.well-known/webauthn. Jeśli plik istnieje, przeglądarka sprawdza, czy źródło wysyłające żądanie znajduje się na liście allowlist. Jeśli tak, przechodzi do tworzenia klucza dostępu lub uwierzytelniania.

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

Obsługa przeglądarek

Żądania dotyczące powiązanych domen są obsługiwane w przeglądarkach Chrome i Safari. W styczniu 2026 r. Firefox nadal rozważał wprowadzenie tej funkcji. Jego stan możesz śledzić w sekcji Problem z pozycją standardów Mozilli.

Konfigurowanie powiązanych żądań dotyczących punktu początkowego

W tym przykładzie 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żywa żądań 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 powiązanych punktów początkowych, aby używać ror-1.glitch.me jako identyfikatora RP, więc zarówno ror-1, jak i ror-2 używają 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 wrażenia użytkownika:

• Możesz utworzyć klucz dostępu i użyć go do uwierzytelnienia na stronie ror-2, mimo że jej identyfikator RP to ror-1 (a nie ror-2).
• Po utworzeniu klucza dostępu na urządzeniu ror-1 lub ror-2 możesz używać go do uwierzytelniania na obu tych urządzeniach.ror-1ror-2 Ponieważ ror-2 określa ror-1 jako identyfikator RP, wysłanie żądania utworzenia klucza dostępu lub uwierzytelnienia z dowolnej z tych witryn jest równoznaczne z wysłaniem żądania w witrynie ror-1. Identyfikator RP to jedyny element, który wiąże żądanie ze źródłem.
• Gdy utworzysz klucz dostępu na urządzeniu ror-1 lub ror-2, Chrome może automatycznie uzupełniać go na obu tych urządzeniach.ror-1ror-2
• Dane logowania utworzone w dowolnej z tych witryn będą miały identyfikator RP ror-1.

Wyświetl kod:

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

Krok 1. Wdróż wspólną bazę danych kont

Jeśli chcesz, aby użytkownicy mogli logować się za pomocą tego samego klucza dostępu na stronach 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 1

Najpierw skonfiguruj site-1.com tak, aby zezwalał na używanie go przez site-2.com 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 pochodzeniem internetowym.

Ważne ograniczenie: maksymalnie 5 etykiet

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

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

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

Na przykład w przypadku dostawy ekspresowej:

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

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

Krok 4. Określ identyfikator RP w witrynie 2

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

• Po utworzeniu danych logowania:
  • Ustaw site-1.com jako identyfikator RP w procesie tworzenia danych logowania options, które są przekazywane do wywołania frontendu navigator.credentials.create i zwykle generowane po stronie serwera.
  • Ustaw site-1.com jako oczekiwany identyfikator RP, ponieważ przed zapisaniem go w bazie danych przeprowadzasz weryfikację danych logowania.
• Po uwierzytelnieniu:
  • Ustaw site-1.com jako identyfikator RP w uwierzytelnianiu options, które są przekazywane do wywołania frontendu navigator.credentials.get i zwykle generowane po stronie serwera.
  • Ustaw site-1.comjako oczekiwany identyfikator RP, który ma być weryfikowany na serwerze, ponieważ przed uwierzytelnieniem użytkownika przeprowadzasz weryfikację danych logowania.

Rozwiązywanie problemów

Inne uwagi

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

Powiązane żądania pochodzenia umożliwiają użytkownikom ponowne używanie klucza dostępu na wielu stronach. Aby umożliwić użytkownikom ponowne używanie klucza dostępu w witrynie i aplikacji mobilnej, zastosuj te techniki:

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

Udostępnianie haseł na różnych stronach

Żądania dotyczące powiązanych źródeł umożliwiają użytkownikom ponowne używanie klucza dostępu w różnych witrynach. Rozwiązania do udostępniania haseł w różnych 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 programó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ą Twoi użytkownicy. Zamiast tego agenci użytkownika i menedżerowie danych logowania powinni informować użytkowników, gdzie zostały użyte ich dane logowania. Wprowadzenie tej zmiany zajmie trochę czasu. Tymczasowym rozwiązaniem może być wyświetlanie zarówno obecnej witryny, jak i pierwotnej witryny rejestracyjnej.