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

Maud Nalpas
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 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.

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

  • Strony z wieloma domenami: użytkownicy nie mogą używać tego samego klucza dostępu do logowania się w różnych domenach (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

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

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

Aby używać żądań z powiązanego źródła, musisz udostępnić 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 pochodzenie wysyłające żądanie znajduje się na liście dozwolonych. Jeśli tak, przechodzi do tworzenia klucza dostępu lub weryfikacji. 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: oczekuje na pozycję.

W tym pokazie użyto 2 witryn: https://ror-1.glitch.mehttps://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ń 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 się 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 się 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.
  • Użytkownik, który utworzy dane logowania na dowolnej z tych witryn, będzie miał identyfikator RP o wartości ror-1.
Chrome wypełnia pola na obu stronach.
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 wypełnia też dane logowania.

Wyświetl kod:

  • Sprawdź, czy plik ./well-known/webauthn jest skonfigurowany w kodeksie źródłowym 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 w site-1site-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ć tego identyfikatora 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 adresami stron internetowych.

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.ukexample.de to example. Etykieta eTLD+1 domeny 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 trybie ekspresowym:

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 tam, 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 RP, gdy przeprowadzasz weryfikację 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 zazwyczaj generowany po stronie serwera.
    • Ustaw site-1.com jako oczekiwany identyfikator RP do zweryfikowania na serwerze, ponieważ przed uwierzytelnieniem użytkownika należy przeprowadzić weryfikację danych logowania.

Rozwiązywanie problemów

Komunikat o błędzie w Chrome
Komunikat o błędzie w Chrome podczas tworzenia danych logowania. Ten błąd występuje, gdy nie można znaleźć pliku „.well-known/webauthn” pod adresem „https://{RP ID}/.well-known/webauthn”.
Komunikat o błędzie w Chrome
Komunikat o błędzie w Chrome podczas tworzenia danych logowania. Ten błąd jest zgłaszany, jeśli plik „.well-known/webauthn” jest dostępny, ale nie zawiera listy pochodzenia, z którego próbujesz utworzyć dane logowania.

Inne uwagi

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

Powiązane prośby o pozwolenie na dostęp do Origin 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 witrynieaplikacji mobilnej, zastosuj te techniki:

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 menedżerowie użytkowników i danych logowania powinni pokazywać użytkownikom, gdzie zostały użyte ich dane logowania. Wdrożenie tej zmiany może trochę potrwać. Tymczasowym rozwiązaniem jest wyświetlanie zarówno bieżącej witryny, jak i pierwotnej witryny rejestracji.