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 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
iexample.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
iacmerewards.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ę.
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 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 toror-1
(a nieror-2
). - Po utworzeniu klucza dostępu na urządzeniu
ror-1
lubror-2
możesz uwierzytelniać się za jego pomocą na obu urządzeniach.ror-1
ror-2
Ponieważror-2
określaror-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
lubror-2
, Chrome może automatycznie go wypełniać zarówno naror-1
, jak i naror-2
. - Użytkownik, który utworzy dane logowania na dowolnej z tych witryn, będzie miał identyfikator RP o wartości
ror-1
.
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-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ć 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.uk
i example.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 logowaniaoptions
, które są przekazywane do wywołanianavigator.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.
- Ustaw
- Po uwierzytelnieniu:
- Ustaw wartość
site-1.com
jako identyfikator RP w procesie uwierzytelnianiaoptions
, który jest przekazywany do wywołanianavigator.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.
- Ustaw wartość
Rozwiązywanie problemów
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 witrynie i aplikacji mobilnej, zastosuj te techniki:
- 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 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.