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
iexample.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
iacmerewards.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.
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ę.
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
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 toror-1
(a nieror-2
). - Po utworzeniu klucza dostępu w systemie
ror-1
lubror-2
możesz go używać w systemachror-1
iror-2
do uwierzytelniania. Ponieważror-2
określaror-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
lubror-2
, Chrome może go automatycznie uzupełnić zarówno w systemieror-1
, jak iror-2
. - Dane logowania utworzone w dowolnej z tych witryn będą miały identyfikator RP o wartości
ror-1
.
![Chrome będzie korzystać z autouzupełniania na obu stronach.](https://web.dev/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=pl)
Zobacz kod:
- Zobacz konfigurację pliku
./well-known/webauthn
w bazie kodu ror-1. - Zobacz wystąpienia
RP_ID_ROR
w bazie kodu ror-2.
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.
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
.
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 logowaniaoptions
, które są przekazywane do funkcjinavigator.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.
- Ustaw
- Po uwierzytelnieniu:
- Ustaw
site-1.com
jako identyfikator RP w uwierzytelnianiuoptions
przekazywane do wywołania frontendunavigator.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.
- Ustaw
Rozwiązywanie problemów
![Wyskakujące okienko z komunikatem o błędzie w Chrome.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=pl)
![Wyskakujące okienko z komunikatem o błędzie w Chrome.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=pl)
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.