WebAuthn Related Origins: Ein Guide für domainübergreifende Passkeys

Passkeys sind der neue Standard für sichere und benutzerfreundliche Authentifizierung. Sie basieren auf den FIDO/WebAuthn-Standards und nutzen Public-Key-Kryptografie, um einen inhärenten Schutz vor Phishing und Credential Stuffing zu bieten. Das verbessert die Sicherheit erheblich und vereinfacht gleichzeitig das Login-Erlebnis für die User. Für Unternehmen bedeutet das spürbare Geschäftsvorteile: geringere Betriebskosten durch weniger Passwort-Resets und SMS-OTPs, minimierte finanzielle Risiken durch Betrug bei Kontoübernahmen und höhere Umsätze durch bessere Conversion Rates.

Eine der größten Sicherheitsstärken von WebAuthn – die strikte Bindung an den „Origin“ (die Herkunftsdomain) – stellt globale Marken und Unternehmen mit vielfältigen digitalen Auftritten jedoch vor eine große Herausforderung. Ein Passkey, der für eine bestimmte Web-Domain erstellt wird, ist kryptografisch an diese Domain gebunden. Das ist ein Grundprinzip, um Phishing-Angriffe zu verhindern. Obwohl dies eine starke Sicherheitsfunktion ist, führt es zu einer fragmentierten und verwirrenden User Experience, wenn eine Marke über mehrere Domains hinweg agiert.

Ein bekanntes Beispiel für diese Herausforderung ist die Umbenennung von Twitter zu X. Ein User, der einen Passkey auf twitter.com erstellt hat, konnte diesen auf x.com nicht verwenden. Das zwang das Unternehmen, umständliche Weiterleitungen zu implementieren oder von den Usern eine erneute Registrierung zu verlangen. Das erzeugt Reibung, die der Akzeptanz direkt im Weg steht. Dies ist kein Einzelfall. Große Unternehmen wie Amazon agieren über zahlreiche länderspezifische Top-Level-Domains (ccTLDs) wie amazon.com, amazon.de und amazon.co.uk, die alle ein gemeinsames Nutzerkontensystem nutzen. In der Welt vor Passkeys konnten Passwort-Manager diese Komplexität geschickt handhaben. Das Standardverhalten von WebAuthn würde jedoch für jede Domain einen separaten Passkey erfordern, was die User frustriert und das Versprechen eines nahtlosen Logins untergräbt.

Um diese kritische Hürde bei der Einführung zu überwinden, hat das W3C eine neue Funktion im WebAuthn-Standard eingeführt: Related Origin Requests (ROR). Dieser leistungsstarke Mechanismus bietet eine standardisierte und sichere Möglichkeit für eine Gruppe vertrauenswürdiger Domains, einen einzigen Passkey zu teilen. So entsteht ein einheitliches und nahtloses Authentifizierungserlebnis im gesamten digitalen Ökosystem einer Marke. Dieser Deep Dive beleuchtet die technischen Grundlagen von ROR, bietet eine praktische Anleitung zur Implementierung und analysiert die strategischen Auswirkungen auf moderne Authentifizierungsarchitekturen.

Die Einführung von ROR markiert einen wichtigen Reifeprozess des WebAuthn-Standards. Die ursprünglichen Spezifikationen konzentrierten sich auf die Etablierung kryptografischer und sicherheitstechnischer Grundprinzipien. Die strikte Bindung eines Credentials an eine Relying Party ID (rpID) war dabei ein Eckpfeiler des Anti-Phishing-Designs. Als groß angelegte Unternehmensimplementierungen durch Firmen wie Amazon und Google Realität wurden, wurde die praktische Reibung, die durch diese Strenge entstand, offensichtlich. Diese Reibung ist ein direktes Hindernis für eine hohe User-Akzeptanz, die der ultimative Erfolgsmaßstab für jedes Passkey-Projekt ist. Die Entwicklung von ROR ist eine direkte Reaktion auf dieses Feedback aus der Unternehmenswelt und zeigt eine pragmatische Weiterentwicklung des Standards. Sie erkennt an, dass die Benutzerfreundlichkeit eines Sicherheitsprotokolls skalierbar sein muss, um den komplexen Geschäftsrealitäten und Markenstrategien der einsetzenden Organisationen gerecht zu werden, damit es sich auf breiter Front durchsetzen kann.

Dieser umfassende Guide beantwortet fünf entscheidende Fragen zur Implementierung von WebAuthn Related Origin Requests:

1. Warum funktionieren Passkeys nicht über mehrere Domains hinweg? Einblicke in das an den Origin gebundene Sicherheitsmodell von WebAuthn und die damit verbundenen praktischen Reibungspunkte.
2. Wie funktionieren Related Origin Requests technisch? Ein Deep Dive in den Validierungsablauf des Browsers und den .well-known-URI-Mechanismus.
3. Was ist für die Implementierung von ROR erforderlich? Eine schrittweise Anleitung für die serverseitige und clientseitige Konfiguration mit praktischen Code-Beispielen.
4. Wann sollte man ROR einem föderierten Login vorziehen? Ein strategischer Entscheidungsrahmen, der ROR mit OIDC/SAML-Ansätzen vergleicht.
5. Wie geht man mit Browser-Kompatibilität und Sicherheitsaspekten um? Aktuelle Support-Matrix und bewährte Sicherheitspraktiken.

Weitere technische Details finden Sie im offiziellen WebAuthn Related Origin Requests Explainer.

Um die Eleganz der Lösung durch Related Origin Requests vollständig zu würdigen, muss man zunächst die zugrunde liegenden technischen Konzepte verstehen, die sie erforderlich machen: die Same-Origin Policy des Webs und die Scoping-Regeln der Relying Party ID (rpID) von WebAuthn. Diese Mechanismen sind grundlegend für die Websicherheit, erzeugen aber genau die Reibung, die ROR beseitigen soll.

Ein „Web Origin“ ist ein kritisches Sicherheitskonzept, das durch die einzigartige Kombination aus Protokoll (z. B. https), Domain (z. B. app.example.com) und Port (z. B. 443) definiert wird, von der Inhalte bereitgestellt werden. Die Same-Origin Policy ist ein vom Browser durchgesetzter Sicherheitsmechanismus, der einschränkt, wie ein von einem Origin geladenes Skript mit einer Ressource von einem anderen Origin interagieren kann. Sie ist ein wichtiges Element der Websicherheit, indem sie potenziell bösartige Dokumente effektiv isoliert und verhindert, dass eine betrügerische Website beispielsweise sensible Daten aus der authentifizierten Webmail-Sitzung eines Users in einem anderen Tab liest.

Im WebAuthn-Ökosystem ist die „Relying Party“ (RP) die Website oder Anwendung, bei der sich ein User zu authentifizieren versucht. Jeder Passkey wird zum Zeitpunkt seiner Erstellung kryptografisch an eine Relying Party ID (rpID) gebunden. Die rpID ist ein Domainname, der den Geltungsbereich und die Grenze für dieses Credential definiert.

Standardmäßig ist die rpID die effektive Domain des Origins, auf dem der Passkey erstellt wird. Die Scoping-Regeln von WebAuthn erlauben es einem Origin, eine rpID festzulegen, die entweder seiner eigenen Domain oder einem registrierbaren Domain-Suffix entspricht. Zum Beispiel kann ein Skript, das auf https://www.accounts.example.co.uk läuft, einen Passkey mit einer rpID von folgenden Werten erstellen:

• www.accounts.example.co.uk (die vollständige Domain)
• accounts.example.co.uk
• example.co.uk

Diese Flexibilität ermöglicht es, einen auf einer Subdomain erstellten Passkey auch auf anderen Subdomains derselben übergeordneten Domain zu verwenden, was ein gängiges und notwendiges Muster ist. Die Regeln verbieten jedoch strikt das Festlegen einer rpID, die kein Suffix ist. Dasselbe Skript auf www.accounts.example.co.uk könnte keinen Passkey mit der rpID example.com erstellen, da .com eine andere Top-Level-Domain ist.

Diese strikte Bindung dient einem wichtigen Zweck: der Trennung von Credentials nach Domain-Geltungsbereich. Ein für mybank.com erstellter Passkey kann nicht auf phishing-site.com verwendet werden, da die bösartige Seite nicht die legitime rpID von mybank.com beanspruchen kann. Der Browser wird den Passkey nicht einmal als Option anbieten.

Allerdings ist die rpID selbst nicht die primäre Anti-Phishing-Kontrolle. Der Phishing-Schutz von WebAuthn ergibt sich tatsächlich aus der Origin-Überprüfung im clientDataJSON-Objekt. Bei jeder WebAuthn-Zeremonie erstellt der Browser ein JSON-Objekt mit kritischem Kontext, einschließlich des exakten Origins, der die Anfrage initiiert hat. Dieses gesamte Objekt wird dann vom privaten Schlüssel des Authenticators kryptografisch signiert. Der Server (Relying Party) MUSS diese Signatur überprüfen und, was entscheidend ist, validieren, dass das Origin-Feld im signierten clientDataJSON einem erwarteten, vertrauenswürdigen Wert entspricht. Diese Origin-Überprüfung ist es, die Phishing-Angriffe verhindert.

Mit Related Origin Requests wird das rpID-Scoping gelockert – bar.com kann legitim die rpID von foo.com beanspruchen, nachdem der Browser die .well-known/webauthn-Datei validiert hat –, aber die Anforderung zur Origin-Überprüfung bleibt unverändert. Das clientDataJSON wird den Origin weiterhin wahrheitsgemäß als bar.com angeben. Der Server unter foo.com empfängt diese signierten Daten, überprüft sie und sieht, dass die Anfrage von bar.com kam. Der Server muss dann prüfen, ob bar.com ein erwarteter verwandter Origin ist, bevor er die Authentifizierung akzeptiert. Dies zeigt einen mehrschichtigen Ansatz, der mehr Flexibilität ermöglicht, ohne das Kernprinzip der Origin-Überprüfung zu opfern.

Der Mechanismus der Related Origin Requests führt eine elegante und standardisierte Methode ein, mit der Domains öffentlich eine Vertrauensbeziehung zum Zweck des Teilens von Passkeys deklarieren können. Er nutzt ein etabliertes Web-Muster – den /.well-known/-URI –, um eine überprüfbare und maschinenlesbare „Allowlist“ zu erstellen, die Browser konsultieren können.

Das Kernkonzept ist einfach: Eine Domain, die als primäre, kanonische rpID für eine Reihe von verwandten Websites dient, kann eine spezielle JSON-Datei unter einer standardisierten, „well-known“ URL hosten: https://{rpID}/.well-known/webauthn. Diese Datei fungiert als öffentliches Manifest, das explizit alle anderen Origins auflistet, die offiziell berechtigt sind, Passkeys unter dieser primären rpID zu erstellen und zu verwenden.

Der Validierungsablauf des Browsers wird immer dann ausgelöst, wenn er eine Nichtübereinstimmung zwischen dem aktuellen Origin und der angeforderten rpID feststellt:

1. Ein User auf einer „verwandten“ Seite, wie https://example.co.uk, initiiert eine Passkey-Operation (Erstellung oder Authentifizierung), bei der der clientseitige Code eine andere Domain als rpID angibt, zum Beispiel example.com.
2. Der Browser erkennt diese Nichtübereinstimmung. Nach den alten Regeln hätte dies sofort zu einem SecurityError geführt.
3. Mit ROR-Unterstützung sendet der Browser, bevor er fehlschlägt, eine sichere HTTPS-GET-Anfrage an die well-known-URL der beanspruchten rpID: https://example.com/.well-known/webauthn. Diese Anfrage wird ohne User-Credentials (wie Cookies) und ohne Referrer-Header gesendet, um die Privatsphäre der User zu schützen und Tracking zu verhindern.
4. Der Browser empfängt die JSON-Antwort vom Server. Er parst die Datei und prüft, ob der aktuelle Origin (https://example.co.uk) im origins-Array innerhalb des JSON-Objekts vorhanden ist.
5. Wenn der Origin in der Allowlist gefunden wird, darf die WebAuthn-Operation mit example.com als gültiger rpID fortgesetzt werden. Wenn der Origin nicht gefunden wird oder wenn die Datei fehlt oder fehlerhaft ist, schlägt die Operation wie bisher fehl.

Die Entscheidung, einen /.well-known/-URI zu verwenden, ist bewusst getroffen und richtet ROR an etablierten Webstandards für Service-Discovery und Domain-Kontroll-Validierung aus. Dieser URI-Pfad, definiert durch RFC 8615, wird bereits von zahlreichen kritischen Protokollen verwendet, einschließlich der acme-challenge für die Ausstellung von Let's Encrypt SSL-Zertifikaten und assetlinks.json zur Verknüpfung von Websites mit Android-Anwendungen. Durch die Übernahme dieser Konvention nutzt das W3C ein Muster, das implizit Domain-Besitz voraussetzt. Um eine Datei an diesem spezifischen, standardisierten Pfad zu platzieren, muss man administrative Kontrolle über den Webserver für diese Domain haben. Dies bietet einen einfachen, aber effektiven Nachweis der Kontrolle und macht die Vertrauenserklärung überprüfbar. Wenn der Eigentümer von example.com eine Datei bereitstellt, die example.co.uk als verwandten Origin auflistet, ist dies eine verifizierbare Behauptung. Dieser Web-native Ansatz ist weitaus einfacher und robuster als Alternativen, die während des Standardisierungsprozesses in Betracht gezogen und verworfen wurden, wie die Verwendung kryptografischer Schlüssel zur Signierung von Autorisierungen (RP Keys) oder nicht-domainbasierte zufällige Identifikatoren (RP UUIDs). ROR verankert die Vertrauensbeziehung im bestehenden, gut verstandenen Domain-Kontroll-Modell des Webs.

Die Implementierung von Related Origin Requests erfordert koordinierte Änderungen sowohl auf der Serverseite, um die Origins zu autorisieren, als auch auf der Clientseite, um die gemeinsame rpID aufzurufen. Dieser Abschnitt enthält die praktischen Code- und Konfigurationsdetails, die erforderlich sind, um ein einheitliches Passkey-Erlebnis über Ihre Domains hinweg zu ermöglichen.

Der Server, der die primäre rpID hostet, ist für die Veröffentlichung der Allowlist der verwandten Origins verantwortlich.

Die Autorisierungsdatei muss am exakten Pfad /.well-known/webauthn relativ zum Stammverzeichnis der primären rpID-Domain platziert werden. Es ist entscheidend, dass diese Datei unter den folgenden Bedingungen bereitgestellt wird:

• Protokoll: Sie muss über HTTPS bereitgestellt werden.
• Content-Type: Der HTTP-Response-Header Content-Type muss auf application/json gesetzt sein.
• Dateiendung: Die URL sollte keine .json-Endung enthalten. Der korrekte Pfad ist /webauthn, nicht /webauthn.json.

Die Datei muss ein einzelnes JSON-Objekt mit einem Schlüssel, origins, enthalten, dessen Wert ein Array von Strings ist. Jeder String im Array ist der vollständige Origin (Protokoll, Domain und optionaler Port), der autorisiert wird.

{
    "origins": ["https://example.co.uk", "https://example.de", "https://example.fr"]
}

Beispiel: Für eine rpID von example.com muss die Datei unter https://example.com/.well-known/webauthn bereitgestellt werden (Hinweis: keine .json-Endung).

Sobald der Server mit der .well-known/webauthn-Datei konfiguriert ist, müssen alle verwandten Domains konsistent dieselbe gemeinsame rpID in ihren WebAuthn-API-Aufrufen verwenden. Diese Koordination ist entscheidend für das korrekte Funktionieren von ROR.

Wichtige Koordinationsanforderungen:

1. Verantwortung des Backends: Der Server generiert die kryptografische Challenge und gibt die gemeinsame rpID sowohl bei der Erstellung von Credentials als auch bei Authentifizierungsanfragen an.
2. Verantwortung des Frontends: Alle Client-Anwendungen (example.com, example.co.uk, example.de) müssen dieselbe gemeinsame rpID an die navigator.credentials-API des Browsers übergeben.
3. Konfigurationsmanagement: Die gemeinsame rpID muss als kritischer globaler Konfigurationswert behandelt und konsistent über alle verwandten Websites hinweg angewendet werden.

Eine Fehlkonfiguration auf nur einer Website – bei der sie standardmäßig ihren eigenen Origin als rpID anstelle des gemeinsamen Werts verwendet – wird das einheitliche Passkey-Erlebnis für die User auf dieser Domain unterbrechen.

Wichtig: Der Server MUSS das origin-Feld im clientDataJSON bei jeder Anfrage überprüfen und sicherstellen, dass es mit einem der autorisierten verwandten Origins übereinstimmt. Diese Origin-Überprüfung ist der primäre Schutzmechanismus gegen Phishing.

Related Origin Requests (ROR) und föderierte Identitätsprotokolle (OIDC/SAML) lösen unterschiedliche Probleme. ROR ist kein Ersatz für Single Sign-On, sondern eine Ergänzung, die einen spezifischen, eng gefassten Anwendungsfall adressiert.

ROR eignet sich für eine einzige logische Anwendung, die über mehrere verwandte Domains verteilt ist und dieselbe User-Datenbank teilt:

• Eine Marke, die mehrere länderspezifische TLDs betreibt (z. B. amazon.com, amazon.de, amazon.co.uk)
• Alle Domains teilen dasselbe Backend-Authentifizierungssystem und dieselbe User-Datenbank
• Sie möchten Weiterleitungs-basierte Abläufe vermeiden und die Authentifizierung kontextbezogen für jede Domain halten
• Ihre Domains liegen innerhalb des 5-Label-Limits
• User sollten alle Domains als einen zusammenhängenden Dienst erleben

Was ROR bietet: Derselbe Passkey funktioniert über alle verwandten Domains hinweg, sodass User nicht für jede regionale Seite separate Passkeys erstellen müssen.

Verwenden Sie föderierte Identitätsprotokolle für echtes Single Sign-On über verschiedene Anwendungen hinweg:

• Mehrere Dienste mit separaten User-Datenbanken oder Identitätssystemen
• Unternehmensszenarien, in denen User Zugriff auf viele verschiedene Anwendungen benötigen (Salesforce, Office 365, interne Tools)
• Integration von Drittanbieter-Anwendungen
• Sie benötigen eine zentralisierte Zugriffskontrolle, Audit-Trails und Identity Governance
• Sie überschreiten das 5-Label-Limit für Related Origins

Was OIDC/SAML bietet: Zentralisierte Authentifizierung, bei der sich User einmal bei einem Identity Provider (IdP) anmelden und über sichere Tokens Zugriff auf mehrere Service Provider (SPs) erhalten.

Wichtig: Passkeys können mit beiden Ansätzen verwendet werden. Sie können Passkeys bei einem zentralisierten IdP für föderiertes SSO implementieren oder ROR für eine Multi-Domain-Anwendung nutzen. Treffen Sie die Wahl basierend auf Ihrer Architektur, nicht auf Ihrer Authentifizierungsmethode.

Obwohl ROR eine leistungsstarke technische Lösung ist, sollte ihre Implementierung eine bewusste strategische Entscheidung sein. Architekten und Produktmanager müssen die Vorteile gegen alternative Muster abwägen und die Einschränkungen verstehen, um ein robustes und zukunftssicheres Authentifizierungssystem zu bauen.

Eine wesentliche Einschränkung von ROR ist das „Label-Limit“. Ein „Label“ bezieht sich in diesem Kontext auf die effektive Top-Level-Domain plus eine Ebene (eTLD+1), also den registrierbaren Teil eines Domainnamens. Zum Beispiel:

• shopping.com, shopping.co.uk und shopping.ca teilen sich alle das einzige Label „shopping“
• myshoppingrewards.com führt ein neues, separates Label ein: „myshoppingrewards“
• travel.shopping.com fällt immer noch unter das Label „shopping“

Die WebAuthn Level 3 Spezifikation verlangt von Browser-Implementierungen, dass sie mindestens fünf einzigartige Labels in der origins-Liste unterstützen. Stand 2025 unterstützt kein bekannter Browser mehr als dieses Minimum von fünf Labels. Daher sollten Organisationen ihre ROR-Implementierungen mit diesem harten Limit im Hinterkopf entwerfen – behandeln Sie fünf als das effektive Maximum.

Dieses Limit ist ein bewusster Mechanismus zur Missbrauchsverhinderung. Es hindert Entitäten wie Shared-Hosting-Anbieter (z. B. wordpress.com) daran, einen universellen Passkey zu erstellen, der über Tausende von nicht zusammenhängenden Kunden-Subdomains funktionieren würde, was das Sicherheitsmodell untergraben würde.

Für die meisten Organisationen, selbst für große multinationale Marken, ist dieses Fünf-Label-Limit ausreichend. Zum Beispiel teilen sich Amazons verschiedene länderspezifische TLDs (amazon.com, amazon.de, amazon.co.uk usw.) alle das „amazon“-Label, sodass vier weitere Label-Plätze für andere Marken in ihrem Portfolio wie „audible“ oder „zappos“ verfügbar bleiben.

Die Komplexität der Implementierung von ROR hängt stark davon ab, ob sie in ein neues System eingeführt oder in ein bestehendes nachgerüstet wird.

• Greenfield-Implementierungen: Bei neuen Projekten ist die Strategie unkompliziert. Eine einzige, kanonische Domain sollte von Anfang an als gemeinsame rpID gewählt werden (z. B. die primäre .com-Domain). Diese rpID sollte dann konsistent in der Konfiguration aller verwandten Websites und Anwendungen vom ersten Tag an verwendet werden.
• Bestehende Implementierungen: ROR in ein System nachzurüsten, das bereits Passkeys mit unterschiedlichen rpIDs über seine Domains hinweg im Einsatz hat, ist deutlich komplexer. Eine direkte Migration ist nicht möglich, da bestehende Passkeys dauerhaft an ihre ursprünglichen rpIDs gebunden sind. Der empfohlene Ansatz in diesem Szenario ist die Implementierung eines „Identifier-First“-Login-Flows. Der User wird zunächst aufgefordert, seinen Benutzernamen oder seine E-Mail-Adresse einzugeben. Das Backend führt dann eine Abfrage durch, um festzustellen, mit welcher rpID sein bestehender Passkey verknüpft ist. Schließlich wird der User zum korrekten Origin weitergeleitet, der dieser rpID entspricht, um die Authentifizierungszeremonie abzuschließen. Nach einem erfolgreichen Login kann er zu seiner ursprünglichen Seite zurückgeleitet werden. Dies ist ein erhebliches architektonisches Unterfangen, das sorgfältige Planung und Implementierung erfordert.

Das Verständnis, wie etablierte Unternehmen Related Origin Requests implementieren, liefert wertvolle Einblicke für Ihre eigene Implementierungsstrategie. Nachfolgend finden Sie Beispiele, die auf tatsächlichen Implementierungen basieren (Stand Oktober 2025):

Microsoft verwendet ROR für seine Authentifizierungsinfrastruktur. Die tatsächliche Konfiguration unter login.microsoftonline.com umfasst:

// https://login.microsoftonline.com/.well-known/webauthn
{
    "origins": ["https://login.microsoftonline.com", "https://login.live.com"]
}

Dieser konservative Ansatz ermöglicht das Teilen von Passkeys zwischen den Unternehmens- und Verbraucher-Login-Portalen von Microsoft und bewahrt gleichzeitig einen fokussierten Sicherheitsperimeter.

Shopify implementiert ROR, um die Authentifizierung über ausgewählte Domains zu vereinheitlichen:

// https://shopify.com/.well-known/webauthn
{
    "origins": ["https://shopify.com", "https://shop.app"]
}

Diese Konfiguration ermöglicht es Shopify, seine Hauptplattform mit seiner Shop-App zu verbinden, was einen gezielten Ansatz für Related Origins demonstriert.

Amazon hat eine ziemlich große Datei:

// https://amazon.com/.well-known/webauthn
{
    "origins": [
        "https://www.amazon.com",
        "https://www.amazon.com.br",
        "https://www.amazon.com.mx",
        "https://www.amazon.ca",
        "https://www.amazon.co.uk",
        "https://www.amazon.de",
        "https://www.amazon.it",
        "https://www.amazon.es",
        "https://www.amazon.nl",
        "https://www.amazon.se",
        "https://www.amazon.sa",
        "https://www.amazon.pl",
        "https://www.amazon.com.tr",
        "https://www.amazon.fr",
        "https://www.amazon.com.au",
        "https://www.amazon.sg",
        "https://www.amazon.ae",
        "https://www.amazon.eg",
        "https://www.amazon.co.za",
        "https://www.amazon.in",
        "https://brandregistry.amazon.com",
        "https://sellercentral.amazon.com",
        "https://sellercentral.amazon.com.br",
        "https://sellercentral.amazon.com.mx",
        "https://sellercentral.amazon.ca",
        "https://sellercentral.amazon.co.uk",
        "https://sellercentral.amazon.de",
        "https://sellercentral.amazon.it",
        "https://sellercentral.amazon.es",
        "https://sellercentral.amazon.nl",
        "https://sellercentral.amazon.se",
        "https://sellercentral.amazon.sa",
        "https://sellercentral.amazon.pl",
        "https://sellercentral.amazon.com.tr",
        "https://sellercentral.amazon.fr",
        "https://sellercentral.amazon.com.au",
        "https://sellercentral.amazon.sg",
        "https://sellercentral.amazon.ae",
        "https://sellercentral.amazon.eg",
        "https://sellercentral.amazon.co.za",
        "https://sellercentral.amazon.in",
        "https://na.account.amazon.com",
        "https://vendorcentral.amazon.com",
        "https://vendorcentral.amazon.com.br",
        "https://vendorcentral.amazon.com.mx",
        "https://vendorcentral.amazon.ca",
        "https://vendorcentral.amazon.co.uk",
        "https://vendorcentral.amazon.de",
        "https://vendorcentral.amazon.it",
        "https://vendorcentral.amazon.es",
        "https://vendorcentral.amazon.nl",
        "https://vendorcentral.amazon.se",
        "https://vendorcentral.amazon.pl",
        "https://vendorcentral.amazon.com.tr",
        "https://vendorcentral.amazon.fr",
        "https://vendorcentral.amazon.com.au",
        "https://vendorcentral.amazon.co.za"
    ]
}

Dieses Muster würde es einer Marke ermöglichen, eine einheitliche Passkey-Authentifizierung über regionale Domains hinweg anzubieten, während die primäre .com-Domain als rpID verwendet wird.

Diese Praxisbeispiele zeigen mehrere Schlüsselmuster auf:

1. Primäre Domain als rpID: Alle Unternehmen verwenden ihre primäre .com-Domain als kanonische rpID.
2. Logische Gruppierung: Origins werden nach Geschäftsfunktion statt nach technischer Architektur gruppiert.
3. Konservativer Geltungsbereich: Die meisten Implementierungen bleiben weit unter dem 5-Label-Limit und verwenden typischerweise 3-4 Origins.
4. Subdomain-Strategie: Viele verwenden Subdomains der primären Domain, um die Markenkonsistenz zu wahren.

Als moderner Webstandard wurde ROR mit Sicherheit als Hauptaugenmerk entwickelt und wird aktiv von den großen Browsern übernommen.

Related Origin Requests beeinträchtigen nicht die zentralen Anti-Phishing-Garantien von WebAuthn. Der Mechanismus ist sorgfältig konzipiert, um eine starke Sicherheitsposition beizubehalten:

• Origin-Überprüfung: Wie besprochen, enthält der Browser weiterhin den wahren Origin der Anfrage im signierten clientDataJSON. Der Relying-Party-Server MUSS diesen Origin überprüfen, um sicherzustellen, dass die Anfrage von einer erwarteten Quelle kommt. Dies verhindert, dass ein kompromittierter verwandter Origin einen anderen imitiert.
• Sicherer Abruf: Die Anfrage des Browsers an die .well-known/webauthn-Datei erfolgt über HTTPS. Darüber hinaus schreibt die Spezifikation vor, dass dieser Abruf ohne Anmeldeinformationen (z. B. Cookies) und ohne Referer-Header durchgeführt wird. Dies verhindert, dass die Anfrage zum Leaken von Benutzerinformationen oder für Cross-Site-Tracking-Zwecke verwendet wird.
• Serversicherheit: Die .well-known/webauthn-Datei selbst wird zu einem kritischen Sicherheits-Asset. Ein Angreifer, der die Kontrolle über den Webserver erlangt, der die primäre rpID hostet, könnte diese Datei potenziell ändern, um seine eigene bösartige Domain zur Allowlist hinzuzufügen. Daher ist die Absicherung der Infrastruktur, die diese Datei bereitstellt, von größter Bedeutung.

Related Origin Requests ist eine Funktion der WebAuthn Level 3 Spezifikation. Die Browser-Unterstützung wurde Ende 2024 eingeführt:

Wichtige Fakten:

• Chrome und Edge: Unterstützung für ROR in Version 128 hinzugefügt (August 2024)
• Safari: Unterstützung für ROR in Safari 18 hinzugefügt, verfügbar auf macOS 15 und iOS 18 (September 2024)
• Firefox: Derzeit keine Unterstützung für ROR; Feature-Erkennung und Fallback-Flows implementieren

Für Anwendungen, die ältere Browser oder Firefox unterstützen müssen, sollte eine Fallback-Strategie implementiert werden:

1. Feature-Erkennung: Überprüfen Sie die ROR-Unterstützung mit PublicKeyCredential.getClientCapabilities()
2. Identifier-First-Flow: Fordern Sie Benutzername/E-Mail an, suchen Sie die zugehörige rpID des Benutzers und leiten Sie dann zum entsprechenden Origin zur Authentifizierung weiter
3. Graceful Degradation: Erlauben Sie Benutzern, separate Passkeys pro Domain zu erstellen, wenn ROR nicht verfügbar ist

Die Daten basieren auf aktuellen Support-Matrizen von Oktober 2025.

Die Implementierung von Related Origin Requests erfordert eine sorgfältige Koordination zwischen mehreren technischen Teams und tiefes Fachwissen in WebAuthn-Protokollen. Die Passkey-Einführungsplattform von Corbado beseitigt diese Komplexität, indem sie unternehmensreife Lösungen für Multi-Domain-Passkey-Implementierungen bereitstellt.

Corbado übernimmt die technische Komplexität von Related Origin Requests durch:

• Automatisierte Konfiguration: Unsere Plattform generiert und hostet automatisch die erforderlichen .well-known/webauthn-Dateien mit den richtigen Sicherheitsheadern und JSON-Formatierungen.
• Multi-Domain-Dashboard: Zentralisierte Verwaltungsoberfläche zur Konfiguration von Related Origins für Ihr gesamtes Domain-Portfolio.
• Validierungstools: Integrierte Test- und Validierungsfunktionen, um sicherzustellen, dass Ihre ROR-Konfiguration in allen Browsern und auf allen Plattformen korrekt funktioniert.

Über die technische Implementierung hinaus bietet Corbado das Sicherheitsframework, das Unternehmen benötigen:

• Origin-Überprüfung: Automatische Validierung der clientDataJSON-Origins, um den Missbrauch verwandter Domains zu verhindern.
• Audit-Logging: Umfassende Nachverfolgung der Passkey-Nutzung über alle verwandten Domains hinweg für Compliance- und Sicherheitsüberwachung.
• Incident Response: Echtzeit-Warnungen und automatisierte Reaktionen auf verdächtige domainübergreifende Authentifizierungsversuche.

Für Organisationen mit bestehenden Passkey-Implementierungen bietet Corbado:

• Legacy-Migrationstools: Automatisierte Analyse bestehender rpID-Konfigurationen und Empfehlungen für Migrationspfade.
• Identifier-First-Flows: Vorgefertigte Login-Komponenten, die komplexe Multi-rpID-Szenarien während der Übergangsphasen handhaben.
• API-Integration: RESTful-APIs und SDKs, die sich nahtlos in Ihre bestehende Authentifizierungsinfrastruktur integrieren lassen.

Sind Sie bereit, Related Origin Requests für Ihre Organisation zu implementieren? Das Expertenteam von Corbado kann Ihnen helfen, ein einheitliches Passkey-Erlebnis für Ihr gesamtes digitales Ökosystem zu entwerfen und bereitzustellen. Kontaktieren Sie unser Lösungsteam, um Ihre spezifischen Anforderungen und Ihren Zeitplan zu besprechen.

Das Versprechen von Passkeys liegt in ihrer Fähigkeit, eine Zukunft zu schaffen, die sowohl sicherer als auch bemerkenswert einfacher für die User ist. Damit diese Zukunft jedoch im globalen Maßstab Realität wird, muss der Standard die architektonischen Komplexitäten moderner digitaler Marken berücksichtigen. Die Reibung, die durch streng an Domains gebundene Passkeys entsteht, war ein erhebliches Hindernis für die Einführung bei Organisationen mit vielfältigen Online-Präsenzen.

WebAuthn Related Origin Requests bietet die standardisierte, sichere und elegante Lösung für dieses Problem. Indem ein einziger Passkey nahtlos über eine vertrauenswürdige Gruppe von verwandten Domains funktioniert, beseitigt ROR einen Hauptpunkt der Verwirrung und Frustration bei den Usern.

Dieser Guide hat fünf entscheidende Fragen zur Implementierung von WebAuthn Related Origin Requests beantwortet:

1. Warum funktionieren Passkeys nicht über mehrere Domains hinweg? Das an den Origin gebundene Sicherheitsmodell von WebAuthn bindet Passkeys kryptografisch an spezifische Domains, um Phishing zu verhindern. Dies erzeugt jedoch Reibung, wenn Marken über mehrere Domains wie verschiedene Länder-TLDs agieren.
2. Wie funktionieren Related Origin Requests technisch? ROR verwendet eine standardisierte .well-known/webauthn-Datei, um eine überprüfbare Allowlist von verwandten Domains zu erstellen. Dies ermöglicht es Browsern, die domainübergreifende Passkey-Nutzung durch einen sicheren HTTPS-Abrufprozess zu validieren.
3. Was ist für die Implementierung von ROR erforderlich? Die Implementierung erfordert die serverseitige Konfiguration der .well-known/webauthn-Manifestdatei und die clientseitige Koordination, um eine gemeinsame rpID konsistent über alle verwandten Origins hinweg zu verwenden.
4. Wann sollte man ROR einem föderierten Login vorziehen? Verwenden Sie ROR für einheitliche Markenerlebnisse über verwandte Domains mit gemeinsamen User-Datenbanken; verwenden Sie OIDC/SAML für echtes SSO über verschiedene Anwendungen hinweg oder wenn das 5-Label-Limit überschritten wird.
5. Wie geht man mit Browser-Kompatibilität und Sicherheitsaspekten um? ROR wird in den wichtigsten Browsern ab Chrome/Firefox 128+, Safari auf macOS 15+ und iOS 18+ unterstützt, wobei Fallback-Strategien für ältere Browser durch Identifier-First-Flows verfügbar sind.

Für technische Teams und Produktverantwortliche sind die wesentlichen Punkte:

• ROR ermöglicht ein einheitliches Passkey-Erlebnis für eine einzige logische Anwendung, die über mehrere Domains verteilt ist, wie z. B. solche mit unterschiedlichen Länder-TLDs oder alternativen Markennamen.
• Die Implementierung erfordert eine koordinierte Anstrengung: Eine serverseitige .well-known/webauthn-Datei muss auf der Domain der primären rpID veröffentlicht werden, und alle clientseitigen Anwendungen müssen so konfiguriert sein, dass sie dieselbe gemeinsame rpID verwenden.
• Die Entscheidung für ROR ist eine strategische. Es ist ein hervorragendes Werkzeug für seine spezifischen Anwendungsfälle, sollte aber gegen eine traditionellere föderierte Login-Architektur (OIDC/SAML) abgewogen werden, insbesondere in Szenarien, die echtes Single Sign-On über unterschiedliche Anwendungen hinweg erfordern.

Funktionen wie Related Origin Requests sind entscheidend für die anhaltende Dynamik der passwortlosen Bewegung. Sie zeigen das Engagement der Standardisierungsgremien, reale Implementierungsherausforderungen anzugehen und sicherzustellen, dass die Vorteile von Passkeys – beispiellose Sicherheit und mühelose User Experience – auch für die größten und komplexesten Organisationen zugänglich sind. Da diese Funktion universelle Browser-Unterstützung erlangt, wird sie eine entscheidende Rolle dabei spielen, die letzten Barrieren zu einem wirklich globalen, passwortlosen Internet zu überwinden.