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

Maud Nalpas

Rozwiązano problem związany z żądaniami dotyczącymi punktu początkowego

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 podmiocie zależnym ID (identyfikator RP). W przypadku kluczy dostępu utworzonych dla domeny example.com może on mieć wartość www.example.com lub example.com.

Chociaż identyfikatory RP uniemożliwiają używanie kluczy dostępu jako danych logowania uwierzytelniają się wszędzie, powodują problemy w tych obszarach:

• Witryny z wieloma domenami: użytkownicy nie mogą używać tego samego klucza dostępu do logować się w różnych domenach krajowych (na przykład example.com i example.co.uk) zarządzane przez tę samą firmę.
• Domeny oznaczone marką: użytkownicy nie mogą używać tych samych danych logowania w różnych domenach. różne domeny używane przez jedną markę (np. acme.com i acmerewards.com).
• Aplikacje mobilne: aplikacje mobilne często nie mają własnej domeny, z trudnościami w zarządzaniu danymi logowania.

Istnieją obejścia problemów oparte na federacji tożsamości, a inne oparte na ale w niektórych przypadkach są niewygodne. Oferta dotycząca powiązanych próśb o dodanie do źródła rozwiązania.

Uwaga: identyfikatory RP stanowią osobne dane uwierzytelniające między różnymi witrynami – ale phishing zabezpieczenie pochodzi z weryfikacji pochodzenia witryny w polu CollectedClientData.

Rozwiązanie

Na Powiązane prośby o dostawę, 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 w kilku obsługiwanych przez Ciebie witrynach.

Aby korzystać z Powiązanego żądania punktu początkowego, musisz udostępnić specjalny plik JSON w konkretny adres URL https://{RP ID}/.well-known/webauthn. Jeśli example.com chce zezwala dodatkowym źródłom na używanie go jako identyfikatora RP, powinien służyć do wyświetlania: 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 prośbę o utworzenie klucza dostępu (navigator.credentials.create) lub uwierzytelnianie (navigator.credentials.get) która używa example.com jako identyfikatora grupy objętej ograniczeniami, przeglądarka zobaczy taki identyfikator, który nie pasuje do źródła żądania. Jeśli przeglądarka obsługuje podobne źródło najpierw szuka webauthn plik pod adresem 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 dozwolonych . Jeśli tak się stanie, rozpocznie się proces tworzenia klucza dostępu lub uwierzytelniania. 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ługiwane od Chrome 128.
• Safari: obsługiwana od wersji macOS 15 beta 3 oraz mobilnych iOS 18 beta 3.
• Firefox: Oczekiwanie na pozycję.

.

Ostrzeżenie: od sierpnia 2024 r. w Firefoksie nie są obsługiwane podobne żądania dotyczące źródła. getClientCapabilities. nie jest jeszcze dostępna, aby wykryć brakującą funkcję i zaimplementować kreacji zastępczej. Jeśli wdrożysz żądania dotyczące powiązanego źródła, użytkownicy Firefoksa nie będą mogli tworzyć klucza dostępu (lub logowania się za jego pomocą) w domenach, które mają używać innej witryny jako identyfikator RP i SecurityError.

Jak skonfigurować powiązane prośby o źródło

W tej prezentacji wykorzystano przykład 2 witryn: https://ror-1.glitch.me i https://ror-2.glitch.me.
Aby umożliwić użytkownikom logowanie się w obu tych witrynach przy użyciu tego samego klucza dostępu, platforma ror-2.glitch.me korzysta z żądań powiązanych z powiązanym źródłem, aby mogła używać ror-1.glitch.me jako identyfikatora RP.

Prezentacja

Uwaga: otwórz wersję demonstracyjną w jednej z obsługiwanych przeglądarek.

Strona https://ror-2.glitch.me implementuje żądania związane z powiązanym źródłem, aby używały ror-1.glitch.me jako identyfikatora RP, więc podczas tworzenia klucza dostępu lub uwierzytelnienia zarówno ror-1, jak i ror-2 używają ror-1.glitch.me jako identyfikatora RP.
Wdrożyliśmy też w tych witrynach współdzieloną bazę danych kluczy.

Przestrzegaj tych zasad:

• Możesz utworzyć klucz dostępu i uwierzytelnić się za jego pomocą w systemie ror-2, mimo że jego identyfikator RP to ror-1 (a nie ror-2).
• Po utworzeniu klucza dostępu w systemie ror-1 lub ror-2 możesz go używać w systemach ror-1 i ror-2 do uwierzytelniania. Ponieważ ror-2 określa ror-1 jako identyfikator RP, wysłanie żądania utworzenia klucza dostępu lub uwierzytelnienia z dowolnej z tych stron jest równoważne z przesłaniem żądania do ror-1. Jedynym elementem, który wiąże żądanie z danym źródłem, jest identyfikator grupy objętej ograniczeniami.
• Gdy utworzysz klucz dostępu w systemie ror-1 lub ror-2, Chrome może go automatycznie uzupełnić zarówno w systemie ror-1, jak i ror-2.
• Dane logowania utworzone w dowolnej z tych witryn będą miały identyfikator RP o wartości ror-1.

.

. Dzięki żądaniu dotyczącym powiązanego źródła użytkownicy mogą używać tych samych danych uwierzytelniających klucza dostępu w ror-1 i ror-2. Chrome będzie też automatycznie uzupełniać dane logowania.

Zobacz kod:

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

.

Uwaga: w tej wersji demonstracyjnej dla uproszczenia weryfikacja hasła nie odbywa się w tle. Wersja demonstracyjna dotyczy kluczy dostępu.

Krok 1. Wdróż bazę danych współdzielonego konta

Jeśli chcesz, aby użytkownicy mogli logować się przy użyciu tego samego klucza dostępu site-1 i site-2, zaimplementuj bazę danych konta, która będzie udostępniana w tych usługach dwóch witryn.

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

Najpierw skonfiguruj site-1.com w taki sposób, aby zezwalał usłudze site-2.com na używanie jej jako Identyfikator strony objętej ograniczeniami. Aby to zrobić, utwórz plik JSON Webauthn:

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

Obiekt JSON musi zawierać klucz o nazwie „origins”, którego wartość jest tablicą z wartością 1 lub kilka ciągów zawierających źródła internetowe.

Ważne ograniczenie: maksymalnie 5 etykiet

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

Ostrzeżenie: jeśli lista zawiera zbyt wiele etykiet (ponad 5), nadmiarowe Liczba elementów zostanie zignorowana.

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

Następnie wyświetlaj plik JSON pod adresem site-1.com/.well-known/webauthn.

Uwaga: plik musi być udostępniany z parametrem content-type application/json i zawierać parametr pojedyncza lista obiektów JSON dozwolone źródła. Prawidłowy format pliku to: /.well-known/webauthn (nie dodawaj rozszerzenia .json).

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 ekspresowego res.json, które już ustawia prawidłowo: content-type ('application/json');

Krok 4. Określ żądany identyfikator grupy objętej ograniczeniami w witrynie 2

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 podczas tworzenia danych logowania options, które są przekazywane do funkcji navigator.credentials.create i zwykle po stronie serwera.
  • Ustaw site-1.com jako oczekiwany identyfikator RP podczas uruchamiania danych logowania weryfikacji przed zapisaniem jej w bazie danych.
• Po uwierzytelnieniu:
  • Ustaw site-1.com jako identyfikator RP w uwierzytelnianiu options przekazywane do wywołania frontendu navigator.credentials.get oraz zwykle generowane po stronie serwera.
  • Ustaw site-1.com jako oczekiwany identyfikator grupy objętej ograniczeniami do zweryfikowania podczas weryfikacji danych logowania przed uwierzytelnianiem użytkownika.

.

Uwaga: co z origin? A RP name? W bazie kodu witryny-2 oczekiwana wartość origin powinna pozostać niezmieniona (https://site-2.com), ponieważ wskazuje, gdzie dane żądanie skąd pochodzą. Zgodnie z nazwą grupy objętej ograniczeniami (rp.name) jest on w praktyce nieużywany. Możesz pozostawić to pole puste.

Rozwiązywanie problemów

Komunikat o błędzie w Chrome podczas tworzenia danych logowania. Ten błąd jest zgłaszany, jeśli nie można znaleźć pliku.well-known/webauthn pod adresem „https://{ID RP}/.well-known/webauthn”.

.

Komunikat o błędzie w Chrome podczas tworzenia danych logowania. Ten błąd jest zgłaszany, jeśli plik `.well-known/webauthn` może zostać znaleziony, ale nie zawiera listy źródła, z którego próbujesz utworzyć dane logowania.

Inne uwagi

Udostępniaj klucze dostępu na stronach i w aplikacjach mobilnych

Powiązane prośby o źródło umożliwiające użytkownikom ponowne użycie klucza dostępu w wielu witryn. Aby umożliwić użytkownikom ponowne użycie klucza dostępu w witrynie i aplikacji mobilnej: użyj poniższych technik:

• W Chrome: zasób cyfrowy Linki. Więcej informacji: Dodano obsługę Digital Asset Links
• W przeglądarce Safari: Powiązane domeny

Udostępniaj hasła na różnych stronach

Powiązane żądania źródła umożliwiają użytkownikom ponowne korzystanie z klucza dostępu w różnych witrynach. Rozwiązania 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 klientów użytkownika

To wykracza poza Twoje możliwości jako twórcy stron. Pamiętaj jednak, że im dłużej identyfikator grupy objętej ograniczeniami nie powinien być pojęciem widocznym dla użytkowników menedżera danych logowania używanych przez użytkowników. Zamiast tego klienty użytkownika i dane logowania Użytkownicy powinni wskazywać użytkownikom, gdzie były używane ich dane logowania. Ta zmiana ich wdrożenie wymaga czasu. Tymczasowym rozwiązaniem jest wyświetlanie aktualnej witryny i witryny, w której rejestrowano się po rejestracji.