Das Problem Related Origin Requests
Passkeys sind mit einer bestimmten Website verknüpft und können nur für die 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 einzelne Anmeldedaten für die Authentifizierung überall verwendet werden, sie verursachen aber Probleme bei:
- 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 von Ihnen betriebene Websites wiederverwenden.
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"
]
}
Wenn eine dieser Websites das nächste Mal einen Aufruf zum Erstellen eines Passkeys (navigator.credentials.create
) oder zur Authentifizierung (navigator.credentials.get
) sendet, bei dem example.com
als RP-ID verwendet wird, erkennt der Browser eine RP-ID, die nicht mit dem anfragenden Ursprung übereinstimmt. 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, von dem die Anfrage stammt, in dieser Datei auf der Zulassungsliste steht. 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: Unterstützt ab macOS 15 Beta 3 und auf Mobilgeräten ab iOS 18 Beta 3.
- 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. - Nachdem 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 eine Anfrage zur Passkey-Erstellung oder Authentifizierung 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
.
Siehe Code:
- Weitere Informationen finden Sie in der Einrichtung der Datei
./well-known/webauthn
in der ror-1-Codebasis. 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
Das eTLD+1-Label 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-Element res.json
, das bereits den korrekten content-type
('application/json'
) festlegt.
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:
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:
site-1.com
als RP-ID in der Authentifizierungoptions
festlegen die an den Frontend-Aufrufnavigator.credentials.get
übergeben werden. 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
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 finden Sie unter Unterstützung für digitale 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 auf verschiedenen Websites 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 Aufgaben als Website-Entwickler hinaus. Je länger Sie jedoch 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 Administratoren den Nutzern zeigen, wo ihre Anmeldedaten verwendet wurden. Diese Änderung die Implementierung etwas Zeit in Anspruch nimmt. Eine vorübergehende Lösung wäre, sowohl das Attribut die aktuelle Website und die ursprüngliche Registrierungsseite.