Das Problem Related Origin Requests
Passkeys sind mit einer bestimmten Website verknüpft und können nur zur Anmeldung auf der Website verwendet werden, für die sie erstellt wurden.
Dies wird in der vertrauenswürdigen Partei angegeben.
ID (RP-ID). Für Passkeys, die für die Domain beispiel.de erstellt wurden, kann sie www.example.com
oder example.com
sein.
RP-IDs verhindern zwar, dass Passkeys als einzige Anmeldedaten für führen sie zu Problemen bei folgenden Bereichen:
- Websites mit mehreren Domains: Nutzer können nicht denselben Passkey für Folgendes verwenden:
über verschiedene länderspezifische Domains (z. B.
example.com
undexample.co.uk
), die vom selben Unternehmen verwaltet werden. - Markendomains: Nutzer können nicht dieselben Anmeldedaten für mehrere
verschiedene Domains, die von einer einzigen Marke verwendet werden (z. B.
acme.com
undacmerewards.com
. - Mobile Apps: Mobile Apps haben oft keine eigene Domain. ist eine Herausforderung.
Es gibt Behelfslösungen basierend auf der Identitätsföderation und andere basierend auf iFrames. Sie sind jedoch in einigen Fällen umständlich. Angebot für zugehörige Ursprungsanfragen eine Lösung finden.
Lösung
Mit Zugehörige Ursprungsanfragen kann eine Website Ursprünge angeben, die ihre RP-ID verwenden dürfen.
So können Nutzer denselben Passkey für mehrere Websites verwenden, die Sie betreiben.
Wenn Sie ähnliche Ursprungsanfragen verwenden möchten, müssen Sie eine spezielle JSON-Datei an einem
bestimmte URL https://{RP ID}/.well-known/webauthn
. Wenn example.com
Folgendes tun möchte:
zusätzlichen Ursprüngen erlauben, sie als RP-ID zu verwenden, sollte Folgendes bereitgestellt werden:
Datei unter https://example.com/.well-known/webauthn:
{
"origins": [
"https://example.co.uk",
"https://example.de",
"https://example-rewards.com"
]
}
Das nächste Mal, wenn eine dieser Websites zur Erstellung eines Passkeys aufruft
(navigator.credentials.create
) oder Authentifizierung (navigator.credentials.get
)
example.com
als RP-ID verwendet, erkennt der Browser eine RP-ID,
stimmt nicht mit dem anfragenden Ursprung überein. Wenn der Browser „Related Origin“ unterstützt
sucht sie zuerst nach einem
webauthn
-Datei unter https://{RP ID}/.well-known/webauthn
. Wenn die Datei vorhanden ist,
prüft der Browser, ob der Ursprung, der die Anfrage stellt, auf der Zulassungsliste steht.
-Datei. Falls ja, werden die Schritte zur Passkey-Erstellung oder zur Authentifizierung durchgeführt.
Wenn der Browser Related Origin Requests nicht unterstützt, wird der Fehler SecurityError
ausgegeben.
Unterstützte Browser
- Chrome: ab Chrome unterstützt 128 aus.
- Safari: Wird ab macOS 15 Beta 3 und auf Mobilgeräten mit iOS 18 Beta 3 unterstützt.
- Firefox: Warten auf Position.
Anfragen wegen verwandter Herkunft einrichten
In der folgenden Demo wird das Beispiel der beiden Websites https://ror-1.glitch.me
und https://ror-2.glitch.me
verwendet.
Damit sich Nutzer auf beiden Websites mit demselben Passkey anmelden können, werden Anfragen zu ähnlichem Ursprung verwendet, um ror-2.glitch.me
zu erlauben, ror-1.glitch.me
als RP-ID zu verwenden.
Demo
https://ror-2.glitch.me implementiert ähnliche Anfragen zum Ursprung, um ror-1.glitch.me als RP-ID zu verwenden, sodass sowohl ror-1
als auch ror-2
ror-1.glitch.me
als RP-ID verwenden, wenn sie einen Passkey erstellen oder sich damit authentifizieren.
Außerdem haben wir auf diesen Websites eine gemeinsame Passkey-Datenbank implementiert.
Beachten Sie die folgende Nutzererfahrung:
- Du kannst unter
ror-2
einen Passkey erstellen und sich damit authentifizieren, auch wenn die RP-IDror-1
(und nichtror-2
) lautet. - Wenn du einen Passkey auf
ror-1
oderror-2
erstellt hast, kannst du dich damit sowohl aufror-1
als auch aufror-2
authentifizieren. Daror-2
ror-1
als RP-ID angibt, entspricht die Anfrage zum Erstellen oder zur Authentifizierung eines Passkeys von einer dieser Websites der Anfrage an ror-1. Die RP-ID ist das Einzige, das eine Anfrage mit einem Ursprung verknüpft. - Wenn du in
ror-1
oderror-2
einen Passkey erstellt hast, kann er von Chrome sowohl aufror-1
als auch aufror-2
automatisch ausgefüllt werden. - Anmeldedaten, die auf einer dieser Websites erstellt werden, haben die RP-ID
ror-1
.
![Chrome füllt das automatische Ausfüllen auf beiden Websites aus.](https://web.dev/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=de)
Siehe Code:
- Weitere Informationen finden Sie in der Einrichtung der Datei
./well-known/webauthn
in der ror-1-Codebasis. - Siehe
RP_ID_ROR
-Vorkommen in der ror-2-Codebasis.
Schritt 1: Gemeinsam genutzte Kontodatenbank implementieren
Wenn Sie möchten, dass sich Ihre Nutzer auf allen Geräten mit demselben Passkey anmelden können
site-1
und site-2
implementieren eine Kontodatenbank, die von diesen gemeinsam genutzt wird
zwei Websites.
Schritt 2: .well-known/webauthn-JSON-Datei in site-1 einrichten
Konfigurieren Sie zuerst site-1.com
so, dass site-2.com
es als
RP-ID. Erstellen Sie dazu Ihre Webauthn-JSON-Datei:
{
"origins": [
"https://site-2.com"
]
}
Das JSON-Objekt muss einen Schlüssel mit dem Namen „origins“ enthalten, dessen Wert ein Array von eins ist oder mehr Strings mit Webursprüngen gibt.
Wichtige Einschränkung: Maximal 5 Labels
Jedes Element dieser Liste wird verarbeitet, um die eTLD + 1 Label zu extrahieren.
So sind beispielsweise die eTLD + 1 Labels von example.co.uk
und example.de
beide
example
Die eTLD + 1 von example-rewards.com
ist jedoch example-rewards
.
In Chrome sind maximal fünf Labels zulässig.
Schritt 3: .well-known/webauthn-JSON in site-1 bereitstellen
Stellen Sie dann Ihre JSON-Datei unter site-1.com/.well-known/webauthn
bereit.
Beispiel für Express:
app.get("/.well-known/webauthn", (req, res) => {
const origins = {
origins: ["https://site-2.com"],
};
return res.json(origins);
});
Hier verwenden wir das Express-Symbol res.json
, das den Wert
richtig content-type
('application/json'
);
Schritt 4: Gewünschte RP-ID auf Website-2 angeben
Lege in deiner site-2
-Codebasis site-1.com
als RP-ID fest, die überall benötigt wird:
- Nach dem Erstellen der Anmeldedaten:
<ph type="x-smartling-placeholder">
- </ph>
site-1.com
beim Erstellen von Anmeldedaten als RP-ID festlegenoptions
, die annavigator.credentials.create
übergeben werden Frontend-Aufruf und wird in der Regel serverseitig generiert.- Legen Sie
site-1.com
als erwartete RP-ID fest, wenn Sie die Anmeldedaten ausführen bevor Sie sie in Ihrer Datenbank speichern.
- Nach der Authentifizierung:
<ph type="x-smartling-placeholder">
- </ph>
site-1.com
als RP-ID in der Authentifizierungoptions
festlegen die an den Frontend-Aufrufnavigator.credentials.get
übergeben werden. die in der Regel serverseitig generiert werden.- Legen Sie
site-1.com
als erwartete RP-ID fest, die auf dem -Server, da Sie die Anmeldedaten vor der Authentifizierung des Nutzers überprüfen.
Fehlerbehebung
<ph type="x-smartling-placeholder">![Pop-up mit Fehlermeldungen in Chrome.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=de)
![Pop-up mit Fehlermeldungen in Chrome.](https://web.dev/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=de)
Weitere Hinweise
Passkeys auf Websites und in mobilen Apps teilen
Mit ähnlichen Ursprungsanfragen können Ihre Nutzer einen Passkey für mehrere mehrere Websites. So erlauben Sie Ihren Nutzern, einen Passkey auf einer Website und in einer mobilen App wiederzuverwenden: verwenden Sie die folgenden Techniken:
- In Chrome: Digital Asset Links: Weitere Informationen unter Unterstützung für Digital Asset Links hinzufügen
- In Safari: Verknüpfte Domains.
Passwörter für andere Websites freigeben
Mit ähnlichen Ursprungsanfragen können Ihre Nutzer einen Passkey websiteübergreifend wiederverwenden. Die Lösungen für die websiteübergreifende Freigabe von Passwörtern unterscheiden sich je nach Passwortmanager. Verwenden Sie für den Google Passwortmanager Digital Asset Links . Safari verwendet ein anderes System.
Rolle von Anmeldedaten-Managern und User-Agents
Dies geht über Ihre Tätigkeit als Website-Entwickler hinaus, aber beachten Sie, dass in den längerfristigen sollte die RP-ID kein für den Nutzer sichtbares Konzept im User-Agent oder Anmeldedaten-Manager, den Ihre Nutzer verwenden. Stattdessen werden User-Agents und Anmeldedaten müssen Nutzer sehen, wo ihre Anmeldedaten verwendet wurden. Diese Änderung deren Implementierung einige Zeit in Anspruch nimmt. Eine vorübergehende Lösung wäre, sowohl das Attribut die aktuelle Website und die ursprüngliche Registrierungsseite.