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

Maud Nalpas
Maud Nalpas
X GitHub

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.

Diese wird in der Relying Party ID (RP-ID) angegeben. Für Passkeys, die für die Domain beispiel.de erstellt wurden, kann das www.example.com oder example.com sein.

RP-IDs verhindern zwar, dass Passkeys überall als einzelne Anmeldedaten verwendet werden, verursachen aber Probleme bei:

  • Websites mit mehreren Domains: Nutzer können sich nicht mit demselben Passkey in verschiedenen länderspezifischen Domains (z. B. example.com und example.co.uk) anmelden, die vom selben Unternehmen verwaltet werden.
  • Markendomains: Nutzer können nicht dieselben Anmeldedaten für verschiedene Domains verwenden, die von einer einzelnen Marke verwendet werden (z. B. acme.com und acmerewards.com).
  • Mobile Apps: Mobile Apps haben oft keine eigene Domain, was die Verwaltung von Anmeldedaten erschwert.

Es gibt Problemumgehungen, die auf der Identitätsföderation und auf Iframes basieren, aber sie sind in einigen Fällen nicht praktisch. Hierfür bieten sich ähnliche Ursprungsanfragen an.

Lösung

Mit Anfragen zu ähnlichen Ursprüngen 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 du Anfragen mit ähnlichen Ursprüngen verwenden möchtest, musst du eine spezielle JSON-Datei unter einer bestimmten URL https://{RP ID}/.well-known/webauthn bereitstellen. Wenn example.com den zusätzlichen Ursprüngen erlauben möchte, diese als RP-ID zu verwenden, sollte die folgende Datei unter https://example.com/.well-known/webauthn: bereitgestellt werden:

{
    "origins": [
        "https://example.co.uk",
        "https://example.de",
        "https://example-rewards.com"
    ]
}

Wenn eine dieser Websites das nächste Mal einen Aufruf zur Erstellung 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 Anfragen mit ähnlichen Ursprüngen unterstützt, sucht er zuerst unter https://{RP ID}/.well-known/webauthn nach einer webauthn-Datei. Wenn die Datei vorhanden ist, prüft der Browser, ob die Quelle, von der 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 Anfragen mit ähnlichem Ursprung nicht unterstützt, wird SecurityError zurückgegeben.

Unterstützte Browser

In der folgenden Demo werden die beiden Websites https://ror-1.glitch.me und https://ror-2.glitch.me verwendet.
Damit sich Nutzer mit demselben Passkey auf beiden Websites anmelden können, werden Anfragen mit ähnlichen Ursprüngen verwendet, damit ror-2.glitch.me ror-1.glitch.me als RP-ID verwenden kann.

Demo

https://ror-2.glitch.me implementiert zugehörige Ursprungsanfragen, um ror-1.glitch.me als RP-ID zu verwenden. Daher verwenden sowohl ror-1 als auch ror-2 ror-1.glitch.me als RP-ID, wenn ein Passkey erstellt oder damit authentifiziert wird.
Außerdem haben wir auf diesen Websites eine gemeinsame Passkey-Datenbank implementiert.

Beachten Sie die folgende Nutzererfahrung:

  • Sie können einen Passkey erstellen und sich damit bei ror-2 authentifizieren, auch wenn die RP-ID ror-1 und nicht ror-2 ist.
  • Wenn Sie einen Passkey auf ror-1 oder ror-2 erstellen, können Sie sich damit sowohl auf ror-1 als auch auf ror-2 authentifizieren. Da ror-2 ror-1 als RP-ID angibt, ist eine Anfrage zur Passkey-Erstellung oder Authentifizierung von einer dieser Websites mit einer Anfrage auf ror-1 identisch. Die RP-ID ist das einzige, was 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.
Chrome füllt die Felder auf beiden Websites automatisch aus.
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.

Code ansehen:

  • 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: Datenbank für gemeinsame Konten implementieren

Wenn Sie möchten, dass sich Ihre Nutzer mit demselben Passkey auf site-1 und site-2 anmelden können, implementieren Sie eine Kontodatenbank, die für diese beiden Websites freigegeben ist.

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 verwenden kann. Erstellen Sie dazu Ihre Webauthn-JSON-Datei:

{
    "origins": [
        "https://site-2.com"
    ]
}

Das JSON-Objekt muss den Schlüssel „origins“ enthalten, dessen Wert ein Array mit einem oder mehreren Strings mit Web-Ursprüngen ist.

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 der Labels example.co.uk und example.de beide example. Das eTLD+1-Label von example-rewards.com ist jedoch example-rewards. In Chrome ist die maximale Anzahl von Labels fünf.

Schritt 3: .well-known/webauthn-JSON-Datei auf Website 1 bereitstellen

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

Beispiel in 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 überall dort, wo es erforderlich ist, site-1.com als RP-ID fest:

  • Nach dem Erstellen der Anmeldedaten:
    • Legen Sie site-1.com als RP-ID bei der Erstellung von Anmeldedaten festoptions, die an den navigator.credentials.create-Frontendaufruf übergeben und in der Regel serverseitig generiert werden.
    • Legen Sie site-1.com als erwartete RP-ID fest, wenn Sie Anmeldedaten überprüfen, bevor Sie sie in Ihrer Datenbank speichern.
  • Nach der Authentifizierung:
    • Lege site-1.com als RP-ID in der Authentifizierung fest. options wird an den navigator.credentials.get-Frontendaufruf übergeben und in der Regel serverseitig generiert.
    • Legen Sie site-1.com als erwartete RP-ID fest, die auf dem Server verifiziert werden soll, wenn Sie die Anmeldedatenüberprüfungen vor der Authentifizierung des Nutzers ausführen.

Fehlerbehebung

Pop-up mit Fehlermeldungen in Chrome.
Fehlermeldung in Chrome beim Erstellen von Anmeldedaten. Dieser Fehler wird ausgegeben, wenn die Datei „.well-known/webauthn“ unter „https://{RP ID}/.well-known/webauthn“ nicht gefunden werden kann.
Pop-up-Fehlermeldung in Chrome
Fehlermeldung in Chrome beim Erstellen von Anmeldedaten. Dieser Fehler wird ausgegeben, wenn die Datei „.well-known/webauthn“ gefunden werden kann, aber den Ursprung nicht auflistet, aus dem Sie Anmeldedaten erstellen möchten.

Weitere Hinweise

Passkeys für Websites und mobile Apps freigeben

Mit ähnlichen Ursprungsanfragen können Ihre Nutzer einen Passkey auf mehreren Websites wiederverwenden. Damit Nutzer einen Passkey auf einer Website und in einer mobilen App wiederverwenden können, können Sie die folgenden Methoden verwenden:

Passwörter für Websites freigeben

Mit ähnlichen Ursprungsanfragen können Ihre Nutzer einen Passkey websiteübergreifend wiederverwenden. Die Lösungen zur Freigabe von Passwörtern auf Websites 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 Ihren Aufgabenbereich als Websiteentwickler hinaus. Beachten Sie jedoch, dass die RP-ID langfristig kein für Nutzer sichtbares Konzept im User-Agent oder im Anmeldedaten-Manager Ihrer Nutzer sein sollte. Stattdessen sollten User-Agents und Anmeldedaten-Manager Nutzern anzeigen, wo ihre Anmeldedaten verwendet wurden. Die Implementierung dieser Änderung wird einige Zeit in Anspruch nehmen. Eine vorübergehende Lösung wäre, sowohl die aktuelle Website als auch die ursprüngliche Registrierungswebsite anzuzeigen.