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

Maud Nalpas
Maud Nalpas

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 praktikabel. Hierfür bieten sich Anfragen zu ähnlichen Ursprüngen 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 von Ihnen betriebene Websites wiederverwenden.

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, wird zuerst nach einer webauthn-Datei unter https://{RP ID}/.well-known/webauthn gesucht. Wenn die Datei vorhanden ist, prüft der Browser, ob die Quelle, von der die Anfrage stammt, in dieser Datei auf der Zulassungsliste steht. Ist dies der Fall, wird mit der Erstellung des Passkeys oder den Authentifizierungsschritten fortgefahren. 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 Anfragen zu verbundenen Ursprüngen, um ror-1.glitch.me als RP-ID zu verwenden. So verwenden sowohl ror-1 als auch ror-2 ror-1.glitch.me als RP-ID, wenn sie einen Passkey erstellen oder sich damit authentifizieren.
Außerdem haben wir auf diesen Websites eine gemeinsame Passkey-Datenbank implementiert.

Sehen Sie sich die folgende Nutzererfahrung an:

  • 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 zum Erstellen oder Authentifizieren eines Passkeys 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 Sie einen Passkey auf ror-1 oder ror-2 erstellen, kann er sowohl auf ror-1 als auch auf ror-2 automatisch von Chrome 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. Chrome füllt die Anmeldedaten auch automatisch aus.

Code ansehen:

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: JSON-Datei „.well-known/webauthn“ auf Website 1 einrichten

Konfigurieren Sie zuerst site-1.com so, dass site-2.com es als RP-ID verwenden kann. Erstellen Sie dazu die JSON-Datei „webauthn“:

{
   
"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 das Label für die eTLD+1 zu extrahieren. Beispiel: Die Labels „eTLD + 1“ von example.co.uk und example.de sind 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 in site-2 angeben

Lege in deiner site-2-Codebasis überall dort, wo es erforderlich ist, site-1.com als RP-ID fest:

  • Beim Erstellen von 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 die erwartete RP-ID fest, die auf dem Server überprüft werden soll, wenn Sie Anmeldedaten vor der Authentifizierung des Nutzers überprüfen.

Fehlerbehebung

Pop-up-Fehlermeldung 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 Ihre Nutzer einen Passkey auf einer Website und in einer mobilen App wiederverwenden können, verwenden Sie die folgenden Methoden:

Passwörter für Websites teilen

Mit ähnlichen Ursprungsanfragen können Ihre Nutzer einen Passkey auf verschiedenen Websites 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.