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 związane z żądaniami z pochodzącego źródła

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, co utrudnia zarządzanie 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 służą do oddzielania danych logowania w różnych witrynach, ale ochrona przed wyłudzaniem informacji 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 żądania powiązane z ustrojem źródłowym, 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ę 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ń powiązanych z uródłem, wyrzuca błąd SecurityError.

Obsługa przeglądarek

• Chrome: obsługiwane od wersji 128.
• Safari: obsługiwane od wersji macOS 15 beta 3 i iOS 18 beta 3 na urządzeniach mobilnych.
• 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 może używać ror-1.glitch.me jako identyfikatora RP, korzystając z żądań dotyczących powiązanego źródła.

Prezentacja

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

https://ror-2.glitch.me implementuje żądania dotyczące powiązanego źródła, aby używały ror-1.glitch.me jako identyfikatora RP, więc podczas tworzenia klucza dostępu lub uwierzytelniania przy użyciu adresu ror-1 i ror-2 zarówno ror-1, jak i ror-2 używają adresu 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 żądaniom powiązanych źródeł użytkownicy mogą używać tych samych danych logowania w przypadku żądań 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.
• Sprawdź wystąpienia RP_ID_ROR w kodeksie 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. Wprowadź wspólną bazę danych kont

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 z 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. Prześlij 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 typem treści application/json i zawierać jeden obiekt JSON z listą dozwolonych źródeł. 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 kodzie źródłowym witryny 2 wartość origin powinna pozostać niezmieniona (https://site-2.com), ponieważ wskazuje, skąd ma pochodzić żądanie. 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 żądania dotyczące źródła umożliwiają 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 agentów użytkowników i zarządzających danymi logowania należy pokazać użytkownikom gdzie zostały użyte 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.