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

Maud Nalpas

Rozwiązanie problemu za pomocą żądań dotyczących pochodzenia

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 on określony w identyfikatorze powiązanej strony (RP ID), który w przypadku kluczy dostępu utworzonych dla domeny example.com może mieć wartość www.example.com lub example.com.

Chociaż identyfikatory RP uniemożliwiają używanie kluczy dostępu jako jednego certyfikatu do uwierzytelniania wszędzie, 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ę (na przykład 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 ramkach iframe, ale w niektórych przypadkach są one niewygodne. Powiązane żądania pochodzenia zawierają rozwiązanie.

Rozwiązanie

W przypadku powiązanych żądań punktu początkowego witryna może określać źródła, które mogą używać swojego identyfikatora RP.

Dzięki temu użytkownicy mogą używać tego samego klucza dostępu na wielu stronach.

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

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

Gdy któraś z tych witryn następnym razem wyśle żądanie utworzenia klucza dostępu (navigator.credentials.create) lub uwierzytelnienia (navigator.credentials.get), używając identyfikatora RP example.com, przeglądarka zauważy, że identyfikator RP nie pasuje do źródła żądania. Jeśli przeglądarka obsługuje podobne żądania, najpierw szuka pliku webauthn w folderze https://{RP ID}/.well-known/webauthn. Jeśli plik istnieje, przeglądarka sprawdza, czy źródło wysyłające żądanie znajduje się w tym pliku na liście dozwolonych. Jeśli tak, przechodzi do tworzenia klucza dostępu lub weryfikacji. Jeśli przeglądarka nie obsługuje żądań dotyczących powiązanego źródła, wysyła żądanie SecurityError.

Obsługa przeglądarek

• Chrome: obsługiwany od Chrome 128.
• Safari: obsługiwana od wersji macOS 15 beta 3 oraz urządzeń mobilnych z iOS 18 w wersji beta 3.
• Firefox: Oczekiwanie na pozycję.

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

W tym pokazie użyto 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 witrynach, używa żądań z powiązanego źródła, aby umożliwić witrynie ror-2.glitch.me użycie identyfikatora ror-1.glitch.me jako identyfikatora RP.

Prezentacja

https://ror-2.glitch.me implementuje żądania powiązanych źródeł, 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ą.
W tych witrynach wdrożyliśmy też wspólną bazę danych kluczy dostępu.

Zwróć uwagę na te wrażenia użytkownika:

• Możesz utworzyć klucz dostępu i użyć go do uwierzytelnienia na ror-2, mimo że identyfikator RP to ror-1 (a nie ror-2).
• Po utworzeniu klucza dostępu na urządzeniu ror-1 lub ror-2 możesz uwierzytelniać się za jego pomocą na obu urządzeniach.ror-1ror-2 Ponieważ ror-2 określa ror-1 jako identyfikator RP, wysłanie żądania utworzenia klucza dostępu lub uwierzytelniania z dowolnej z tych witryn jest takie samo jak wysłanie żądania na ror-1. Identyfikator RP to jedyna rzecz, która łączy żądanie z źródłem.
• Gdy utworzysz klucz dostępu na ror-1 lub ror-2, Chrome może automatycznie go wypełniać zarówno na ror-1, jak i na ror-2.
• Dane logowania utworzone w dowolnej z tych witryn będą miały identyfikator RP o wartości ror-1.

Wyświetl kod:

• Zobacz konfigurację pliku ./well-known/webauthn w bazie kodu ror-1.
• Sprawdź wystąpienia RP_ID_ROR w kodeksie ror-2.

Krok 1. Wprowadź wspólną bazę danych kont

Jeśli chcesz, aby użytkownicy mogli logować się za pomocą tego samego klucza dostępu na stronie site-1 i site-2, wdrożyć bazę danych kont, która jest współdzielona na tych dwóch stronach.

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

Najpierw skonfiguruj usługę site-1.com tak, aby usługa site-2.com mogła używać 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 jeden ciąg znaków zawierający adresy internetowe.

Ważne ograniczenie: maksymalnie 5 etykiet

Każdy element z tej listy zostanie przetworzony w celu wyodrębnienia etykiety eTLD+1. 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. Prześlij plik JSON .well-known/webauthn w witrynie 1

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

Na przykład w postaci ekspresowej:

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

Tutaj używamy wyrażenia res.json, które już ustawia prawidłową wartość content-type ('application/json');

Krok 4. W witrynie 2 określ wybrany identyfikator RP

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

• Podczas tworzenia danych logowania:
  • Ustaw site-1.com jako identyfikator RP w procesie tworzenia danych logowania options, które są przekazywane do wywołania navigator.credentials.create na fronendzie i zwykle generowane po stronie serwera.
  • Ustaw site-1.com jako oczekiwany identyfikator grupy objętej ograniczeniami podczas uruchamiania weryfikacji danych logowania przed zapisaniem ich w bazie danych.
• Po uwierzytelnieniu:
  • Ustaw wartość site-1.com jako identyfikator RP w procesie uwierzytelniania options, który jest przekazywany do wywołania navigator.credentials.get po stronie frontendu i zwykle generowany po stronie serwera.
  • Ustaw site-1.com jako oczekiwany identyfikator RP do zweryfikowania na serwerze, ponieważ weryfikację danych logowania przeprowadzasz przed uwierzytelnieniem użytkownika.

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życie klucza dostępu na kilku stronach. Aby umożliwić użytkownikom ponowne użycie klucza dostępu w witrynie i aplikacji mobilnej, użyj tych technik:

• 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ł w różnych witrynach

Żądania z powiązanego źródła umożliwiają użytkownikom ponowne użycie 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 linków do zasobów cyfrowych . Safari ma inny system.

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

To wykracza poza zakres Twoich obowiązków jako dewelopera witryny, ale pamiętaj, że w dłuższej perspektywie czasowej identyfikator RP nie powinien być widoczny dla użytkownika w agentach użytkownika ani w menedżerze danych logowania, z których korzystają użytkownicy. Zamiast tego agenty użytkowników i menedżerowie danych logowania powinni pokazywać użytkownikom, gdzie zostały użyte ich dane logowania. Wprowadzanie tej zmiany może trochę potrwać. Tymczasowe rozwiązanie to wyświetlanie zarówno bieżącej, jak i pierwotnej witryny rejestracji.