Wiederverwendung von Passkeys auf Ihren Websites für Anfragen zu ähnlichen Quellen zulassen

Maud Nalpas

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 und example.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 und acmerewards.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.

Hinweis :Mit RP-IDs werden die Anmeldedaten zwischen verschiedenen Websites getrennt. Phishing wird jedoch durch eine Phishing-ID erkannt. Der Schutz wird tatsächlich durch die Überprüfung des Ursprungs der Website im Feld CollectedClientData ausgelöst.

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.

Warnung :Seit August 2024 werden verwandte Ursprungsanfragen in Firefox nicht mehr unterstützt. getClientCapabilities noch nicht verfügbar ist, um die fehlende Funktion zu ermitteln und eine . Wenn Sie verwandte Ursprungsanfragen implementieren, können Firefox-Nutzer keine einen Passkey (oder sich damit anmelden) in den Domains, die eine andere Website als eine RP-ID und ein SecurityError ausgegeben wird.

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

Hinweis :Öffnen Sie die Demo in einem der unterstützten Browser.

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-ID ror-1 (und nicht ror-2) lautet.
• Wenn du einen Passkey auf ror-1 oder ror-2 erstellt hast, kannst du dich damit sowohl auf ror-1 als auch auf ror-2 authentifizieren. Da ror-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 oder ror-2 einen Passkey erstellt hast, kann er von Chrome sowohl auf ror-1 als auch auf ror-2 automatisch ausgefüllt werden.
• Anmeldedaten, die auf einer dieser Websites erstellt werden, haben die RP-ID ror-1.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> Dank verwandter Ursprungsanfragen können Nutzer dieselben Passkey-Anmeldedaten für ror-1 und ror-2 verwenden. Die Anmeldedaten werden außerdem automatisch von Chrome ausgefüllt.

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.

Hinweis: Der Einfachheit halber wird in dieser Demo im Hintergrund keine Passwortüberprüfung durchgeführt. In der Demo geht es hauptsächlich um Passkeys.

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.

Warnung: Wenn Ihre Liste zu viele Labels (mehr als fünf) enthält, werden die übermäßigen werden ignoriert.

Schritt 3: .well-known/webauthn-JSON in site-1 bereitstellen

Stellen Sie dann Ihre JSON-Datei unter site-1.com/.well-known/webauthn bereit.

Achtung :Die Datei muss mit dem Inhaltstyp application/json bereitgestellt werden und den einzelne JSON-Objektauflistung zulässigen Ursprüngen. Das richtige Format für die Datei ist: /.well-known/webauthn (ohne die Erweiterung .json).

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 festlegen options, die an navigator.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 Authentifizierung options festlegen die an den Frontend-Aufruf navigator.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.

Hinweis: Was ist mit origin? Und die RP name? In Ihrer Codebasis „site-2“ sollte die erwartete origin unverändert bleiben. (https://site-2.com), da dadurch angegeben wird, wo die Anfrage voraussichtlich stammen. Gemäß dem RP-Namen (rp.name) wird er in der Praxis nicht verwendet. Sie können das Feld leer lassen.

Fehlerbehebung

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> Fehlermeldung in Chrome bei der Erstellung der Anmeldedaten. Dieser Fehler wird ausgegeben, wenn die Datei „.well-known/webauthn“ nicht unter „https://{RP ID}/.well-known/webauthn“ gefunden werden kann.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> Fehlermeldung in Chrome bei der Erstellung der Anmeldedaten. Dieser Fehler wird ausgegeben, wenn die Datei „.well-known/webauthn“ gefunden wird, aber der Ursprung, aus dem Sie ein Ausweisdokument erstellen möchten, nicht aufgeführt ist.

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.