Domainübergreifende Anmeldungen defragmentieren

Eiji Kitamura

Moderne Unternehmensarchitekturen umfassen häufig mehrere unterschiedliche Domains. Organisationen unterhalten dedizierte Umgebungen für verschiedene Funktionen, z. B. brand.example für Marketing, service-app.example für das Kernprodukt und support-portal.example für den Kundenservice. Im Idealfall möchten Sie eine einheitliche Einmalanmeldung anbieten, wenn Nutzer zwischen diesen Properties wechseln. Entwicklungsteams integrieren diese Bereiche jedoch häufig mit Ad-hoc-Techniken, die zu einer Fragmentierung führen. Dadurch wird die integrierte Verwaltung von Browseranmeldedaten unterbrochen, da Autofill-Abläufe des Passwortmanagers nicht mehr funktionieren und die Einführung von Passkeys verzögert wird.

Wenn sich dasselbe Konto über mehrere Domains erstreckt, muss der Nutzer erkennen, dass die Domains zur selben Organisation gehören, und dieselben Anmeldedaten für die Anmeldung angeben. Im schlimmsten Fall erstellt der Nutzer ein doppeltes Konto oder gibt das Passwort auf einer Phishing-Website preis.

Hier erfahren Sie, wie Sie mit Architekturstandards und ‑lösungen (z. B. Metadaten, domainübergreifende iFrames, Identitätsföderation und Konsolidierung von Subdomains) die Fragmentierung von Identitäten über verschiedene Domains hinweg beheben und eine nahtlose Nutzererfahrung ermöglichen können.

Häufige Problemumgehungen

Unternehmen verwenden mehrere etablierte Techniken, um einen domainübergreifenden Ablauf aufrechtzuerhalten. Diese Methoden sind zwar gängig, stehen aber vor strukturellen Hürden, da Browser strengere Datenschutzgrenzen und Sicherheitsstandards durchsetzen.

CORS-Abrufanfragen

Wenn Domains unabhängig voneinander funktionieren, sind Frontends häufig auf fetch()-Anfragen mit Ursprungsübergang angewiesen, die an eine zentrale Authentifizierungs-API gerichtet sind. Diese können mit Cross-Origin Resource Sharing (CORS) sicher zugelassen werden. Da Browser häufig websiteübergreifende Cookies blockieren oder einschränken, können Entwickler diese APIs explizit so gestalten, dass sie Authentifizierungstokens wie JSON-Webtokens (JWTs) in JSON-Nutzlasten zurückgeben, anstatt sich auf Set-Cookie-Header zu verlassen.

Datenbankfreigabe für Konto

Um die Identität im Backend ohne komplexe Frontend-Integrationen zu vereinheitlichen, können Sie den Nutzerdatenspeicher zentralisieren. Obwohl mehrere Domains sich bei derselben Datenbank authentifizieren, bleibt die Anmeldung im Frontend für jede Domain separat. Nutzer müssen sich dann merken, für welche Domains sie dieselben Anmeldedaten verwendet haben, was zu einer schlechten Nutzererfahrung führt.

Probleme mit nicht zusammenhängenden Anmeldungen

Mit technischen Umgehungslösungen lässt sich zwar eine grundlegende Funktionalität erreichen, aber keine nahtlose Nutzererfahrung. Unzusammenhängende Anmeldeabläufe führen zu Reibungspunkten, die sowohl die Nutzerfreundlichkeit als auch die Sicherheit beeinträchtigen.

Fragmentierung von Passwortmanagern

Der größte Reibungspunkt ist die Unterbrechung von Passwortmanagern. Passwortmanager binden gespeicherte Anmeldedaten an den jeweiligen Ursprung, an dem sie registriert sind. So wird verhindert, dass der Browser die Autofill-Funktion für verschiedene Domains anbietet, auch wenn sie zur selben Organisation gehören.

Wenn ein Nutzer von einer Domain mit gespeicherten Anmeldedaten zu einer neuen Domain in Ihrer Organisation wechselt, kann der Passwortmanager die Beziehung nicht erkennen und löst die Aufforderung zum automatischen Ausfüllen nicht aus. Dadurch wird die manuelle Eingabe erschwert. Nutzer müssen ihre Anmeldedaten suchen, ihr Passwort zurücksetzen oder ein Duplikatkonto erstellen.

Da der Passwortmanager in diesen Properties nicht zuverlässig funktioniert, verwenden Nutzer die Tools für diese Websites möglicherweise nicht mehr. Stattdessen erstellen sie oft schwache, leicht zu merkende Passwörter, die sie an anderer Stelle wiederverwenden, was die allgemeine Sicherheit Ihrer Organisation beeinträchtigt.

Phishing-Gateway

Diese Störung fungiert als Phishing-Gateway. Die Weigerung eines Passwortmanagers, auf einer unbekannten Domain Autofill zu verwenden, ist ein wichtiger Schutzmechanismus. Wenn Nutzer Anmeldedaten manuell auf verschiedenen URLs eingeben müssen, werden sie unbeabsichtigt darauf trainiert, Phishing-Angriffen zum Opfer zu fallen.

Roadblock für Passkeys

Die Reibung nimmt zu, wenn Sie Passkeys verwenden. Die zentrale Sicherheitsarchitektur von WebAuthn bindet Passkeys kryptografisch streng an eine bestimmte Relying Party-ID (RP-ID).

Dadurch wird eine „RP-ID-Falle“ erstellt. Ein auf brand.example registrierter Passkey kann auf service-app.example nicht verwendet werden, da der Browser den domainübergreifenden Zugriff verweigert. Damit Nutzer nicht aufgefordert werden, für jede Website separate Passkeys zu registrieren, müssen Sie diese Eigenschaften in einer einzigen RP‑ID zusammenfassen.

Empfohlene Vorgehensweisen

Um die Kontinuität der Identität zu gewährleisten, müssen Sie von Ad-hoc-Anmeldeintegrationen zu anerkannten Architekturstandards wechseln:

• Metadaten-Konfigurationsdateien verwenden: Metadatendateien wie Digital Asset Links und Anfragen zu verknüpften Ursprüngen hosten, um eine kryptografische Vertrauenskette zu erstellen. So können Anmeldedaten und Passkeys nahtlos über verschiedene Domains und mobile Apps hinweg geteilt werden. Dieser Ansatz ist eine kostengünstige, stille Lösung für die Identitätsfragmentierung, die keine komplexe Umgestaltung der bestehenden Webinfrastruktur erfordert.
• Cross-Origin-iFrames verwenden: Betten Sie einen zentralen Authentifizierungsursprung als iFrame in eine vertrauende Partei ein, um gespeicherte Anmeldedaten und Passkeys über verschiedene Websites hinweg zu überbrücken. Bei diesem Ansatz werden die Berechtigungsrichtlinie und partitionierte Cookies verwendet, um eine nahtlose, kontextbezogene Anmeldung zu ermöglichen und gleichzeitig strenge Sicherheitsgrenzen durch CSP und die Nachrichtenübermittlung zwischen Dokumenten einzuhalten.
• Standard-Identitätsföderation verwenden: Verwenden Sie Industriestandardprotokolle wie OpenID Connect, um die Authentifizierung in einer dedizierten Identitätsanbieterdomain (IdP) zu zentralisieren. Dadurch wird der Anmeldevorgang durch sichere Weiterleitungen formalisiert und anfällige Integrationen werden durch eine zuverlässige und skalierbare eigene Lösung ersetzt.
• Subdomains zusammenführen: Stellen Sie auf Subdomains unter einem gemeinsamen Stamm um. So können Sitzungen nahtlos über Wildcard-Cookies geteilt werden und Passkeys sind in der gesamten registrierbaren Domain verfügbar. Viele Passwortmanager können die gemeinsame Stammdomain erkennen und automatisch gespeicherte Anmeldedaten für zugehörige Subdomains vorschlagen.

Metadaten-Konfigurationsdateien verwenden

Eine der größten Herausforderungen bei domainübergreifenden Identitäten ist die Fragmentierung gespeicherter Anmeldedaten. Passwortmanager behandeln verschiedene Domains und Apps als völlig isolierte Einheiten. Dadurch wird verhindert, dass Anmeldedaten, die in einer Property gespeichert sind, automatisch in eine andere eingefügt werden.

Um die Fragmentierung zu beheben, können Sie das Verhalten von Passwortmanagern konfigurieren, anstatt die Struktur Ihrer Website zu ändern. Durch das Hosten bestimmter Metadaten-Konfigurationsdateien können Organisationen kryptografisch bestätigen, dass unterschiedliche Domains und Anwendungen zur selben Organisation gehören. So können Betriebssysteme, Browser und Passwortmanager diese Beziehung erkennen und den Identitätskontext automatisch überbrücken, indem sie Passwörter und Passkeys für Ihre Properties freigeben. Dieser Ansatz ist auch erforderlich, um webbasierte Passwörter und Passkeys für mobile Anwendungen freizugeben, selbst wenn Ihre Webdomains konsolidiert sind.

Verwenden Sie zwei verschiedene Konfigurationsdateien, um verschiedene Plattformen und Ökosysteme abzudecken:

• Google Passwortmanager für Android und Chrome: Hosten Sie eine Digital Asset Links (DAL)-JSON-Datei unter /.well-known/assetlinks.json, um eine überprüfbare Vertrauensbeziehung zwischen den zugehörigen Apps und Websites einer Organisation herzustellen. Diese Vertrauensstellung ermöglicht Deeplinks in Apps und Seamless Credential Sharing (nahtloses Teilen von Anmeldedaten), bei dem im Web gespeicherte Passwörter automatisch auf zugehörigen Websites eingefügt werden. Das Teilen von Passkeys über mehrere Webdomains hinweg erfordert jedoch weiterhin Related Origin Requests (Anfragen zu verknüpften Ursprüngen). Weitere Informationen finden Sie im Leitfaden Nahtlose Freigabe von Anmeldedaten.

• Apple-Passwörter unter iOS und Safari: Hosten Sie eine Apple App Site Association-Datei (AASA) unter /.well-known/apple-app-site-association, um die kryptografische Vertrauenskette einzurichten, die für die Überbrückung von Apple-Passwortstatus zwischen iOS-Apps und Safari erforderlich ist. Zur Unterstützung von Drittanbieter-Ökosystemen können Sie diese zugehörigen Domains zentral über ein Crowdsourcing-Repository deklarieren. So wird sichergestellt, dass unabhängige Tools (z. B. 1Password, das dieses Repository explizit nutzt) den gemeinsamen Identitätskontext ebenfalls erkennen. Weitere Informationen zur Apple App Site Association

Damit Passkeys für verschiedene Webdomains aktiviert werden können und das Passkey-Problem behoben wird, können Entwickler eine ROR-Datei (Related Origin Requests) unter /.well-known/webauthn hosten. ROR deklariert explizit autorisierte Domains, die die gleiche Passkey-RP-ID sicher freigeben dürfen. Weitere Informationen zu Anfragen für verknüpfte Ursprünge finden Sie unter Passkey-Wiederverwendung auf Ihren Websites mit Anfragen für verknüpfte Ursprünge zulassen.

• Vorteile:
  • Hintergrundkorrektur für Endnutzer:Die Korrektur erfolgt vollständig im Hintergrund. Die Fragmentierung der Autofill-Funktion wird automatisch behoben und die Kontinuität von Passkeys wird auf Betriebssystem- oder Browserebene hergestellt, ohne dass sich die Benutzeroberfläche sichtbar ändert.
  • Einfache Implementierung:Diese kostengünstige Lösung erfordert nur das Hosten statischer JSON-Dateien. Es ist keine Backend-Neugestaltung oder komplexe Logik für den Tokenaustausch erforderlich.
  • Vorhandene Infrastruktur wird beibehalten:Sie können die domainübergreifende Customer Journey deutlich verbessern, ohne Ihre Marke zu ändern oder Ihre Domains zusammenzuführen.
• Nachteile:
  • Plattformeinschränkungen:Plattformen setzen in der Regel strenge Grenzen für die Reichweite und Häufigkeit von Anzeigen durch. In Chrome ist beispielsweise eine einzelne RP‑ID auf maximal fünf zugeordnete eTLD+1-Labels beschränkt. example.co.uk und example.de haben dasselbe example-Label für eTLD+1, example-rewards.com verwendet jedoch ein separates example-rewards-Label. Wenn Sie ein umfangreiches oder vielfältiges Domainportfolio verwalten, reichen diese Limits möglicherweise nicht aus.
  • Erhöhte betriebliche Latenz: Zum Auflösen von Metadatendateien ist ein zusätzlicher Netzwerk-Roundtrip erforderlich, was die Latenz erhöht, wenn der Browser die Authentifizierung verarbeitet.

Ursprungsübergreifende iFrames verwenden

Wenn Sie die Metadatenkonfigurationsdateien aufgrund von ROR-Domainbeschränkungen nicht verwenden können, bieten iframe-Elemente für ursprungsübergreifende Anfragen eine robuste, standardkonforme Möglichkeit, die Probleme bei der domainübergreifenden Anmeldung zu lösen.

Wenn Sie einen zentralen Authentifizierungsursprung (z. B. auth.brand.example) als iFrame in eine vertrauende Partei (z. B. brand.example) einbetten, können Sie sowohl mit herkömmlichen Formularfeldern als auch mit modernen APIs interagieren. Bei Passwörtern verknüpft der Anmeldedatenmanager des Browsers Autofill-Vorgänge mit dem Ursprung des iFrames (auth.example). So können Nutzer nahtlos auf ihre zentralisierten Anmeldedaten auf verschiedenen Websites zugreifen.

Bei Passkeys muss das übergeordnete Fenster dem iFrame Zugriff über das Permissions Policy-Framework gewähren, damit der iFrame WebAuthn aufrufen kann, um sich mit der RP-ID seines eigenen Ursprungs zu authentifizieren. In beiden Abläufen ist die Content Security Policy (CSP) nützlich, um Nutzer vor Angriffen wie Clickjacking und Cross-Site-Scripting zu schützen. Nach erfolgreicher Authentifizierung wird die Sitzung mit einem partitionierten Cookie eingerichtet und das Token wird sicher über postMessage() an das übergeordnete Fenster zurückgegeben.

• Vorteile:
  • Zentrale Anmeldedaten:Vermeidet die Fragmentierung von Anmeldedaten. Ein einzelner, zentraler Ursprung verwaltet sowohl gespeicherte Passwörter als auch eine einheitliche Passkey-RP-ID. So können verschiedene Domains diese Anmeldedaten gemeinsam nutzen, ohne dass Domains konsolidiert werden müssen.
  • Kontextbezogene Authentifizierung:Der gesamte Anmeldevorgang – ob das Passwort automatisch ausgefüllt oder die Bestätigung mit einem Passkey erfolgt – wird nahtlos im Kontext der übergeordneten Seite ausgeführt. So werden störende föderierte Weiterleitungen vermieden.
  • Widerstandsfähigkeit gegenüber Tracking-Schutzmaßnahmen:Dieser Ansatz funktioniert auch bei strengen websiteübergreifenden Tracking-Schutzmaßnahmen mit partitionierten Cookies korrekt.
• Nachteile:
  • Implementierungseinschränkungen:Diese Architektur erfordert spezielle technische Kenntnisse. Es erfordert eine strenge CSP (frame-ancestors), um das Einbetten auf vertrauenswürdige übergeordnete Domains zu beschränken und Clickjacking zu verhindern, die Konfiguration von HTTP-Berechtigungsrichtlinien zur Aktivierung der WebAuthn API sowie sichere, validierte dokumentübergreifende Nachrichten (postMessage()), um Origin-Spoofing und CSRF-Angriffe zu verhindern. Best Practices für Passkeys in iFrames

Standard-Identitätsföderation verwenden

Die Verwendung von Standard-Identitätsföderation wie OpenID Connect ist ein robuster und nachhaltiger Ansatz für die Verwaltung Ihres Kontosystems. Bei diesem Ansatz wird der Authentifizierungsablauf formalisiert, indem er auf eine einzelne, dedizierte Identitätsanbieterdomain (IdP) wie auth.brand.example konsolidiert wird. Mit einem etablierten Protokoll leiten Anwendungen Nutzer zur Authentifizierung zu diesem zentralen Hub weiter, bevor sie sicher ein Token übertragen, um die Anmeldung in der Zieldomain abzuschließen. Die Standardföderation wird zwar häufig mit Anmeldungen von Drittanbietern (z. B. Über Google anmelden) in Verbindung gebracht, ist aber eine völlig gültige und weit verbreitete Lösung für selbst erhobene Daten, um anfällige Workarounds zu ersetzen.

• Vorteile:
  • Gemeinsame Engineering-Sprache:Entwickler müssen kein spezielles, benutzerdefiniertes Protokoll lernen oder pflegen, sondern können sich auf etabliertes Branchenwissen und umfassende Bibliotheken verlassen. Es gibt auch Paketlösungen.
  • Bewährte Zuverlässigkeit:Standardprotokolle sind bewährt, sicher und viel weniger anfällig als Ad-hoc-Implementierungen.
  • Einfach erweiterbar:Wenn die Organisation später einen neuen Drittanbieterdienst einbinden oder ein Unternehmen übernehmen muss, ist die Identitätsinfrastruktur bereits für die Bereitstellung von Anmeldedaten gerüstet.
  • Einheitliche Benutzeroberfläche:Nutzer erkennen die zentrale IdP-Seite als autoritative Quelle für die Marke und wissen genau, wann und wo Anmeldedaten erforderlich sind.
• Nachteile:
  • Hoher Integrationsaufwand:Die Entwicklung oder Migration zu einem zentralen IdP ist mit einem hohen Integrationsaufwand verbunden und erfordert spezielle Sicherheitskenntnisse. Organisationen müssen in die sichere Umgestaltung aller verbundenen Anwendungen investieren, um sichere umleitungsbasierte Muster zu unterstützen.
  • Störende Weiterleitungen:Für den Authentifizierungsablauf müssen Nutzer von der Ursprungswebsite zu einer zentralen Seite des Identitätsanbieters weitergeleitet werden. Dadurch wird eine nahtlose Anmeldung im Kontext verhindert.

Subdomains zusammenfassen

Ein weiterer struktureller Ansatz besteht darin, alle Domains zu vereinheitlichen, indem Sie unterschiedliche digitale Properties unter einer gemeinsamen registrierbaren Stammdomain (der eTLD+1) zusammenfassen. Dazu müssen separate Domains wie brand.example und service-app.example in Subdomains wie www.brand.example und service.brand.example umgewandelt werden.

• Vorteile:
  • Einheitliche Verwaltung von Anmeldedaten:Passwortmanager können die Stammdomain erkennen und alle Subdomains als einen Eintrag behandeln. So werden doppelte Aufforderungen und die manuelle Eingabe von Passwörtern vermieden.
  • Passkey-Kontinuität:Entwickler können die RP-ID eines Passkeys nativ auf die registrierbare Domain beschränken und so die Passkey-Unterstützung sofort auf alle zugehörigen Subdomains ausweiten. In diesem Fall funktioniert eine RP‑ID von brand.example sowohl bei www.brand.example als auch bei service.brand.example.
  • Einfache Sitzungsfreigabe:Durch die Konsolidierung der Domainstruktur kann eine einzelne Sitzung mithilfe von Platzhalter-Cookies freigegeben werden (z. B. durch Festlegen eines Cookies für Domain=brand.example).
• Nachteile:
  • Einschränkungen bei Branding und Migration:Bei diesem Ansatz können potenzielle Branding-Einschränkungen auftreten, wenn Ihre Organisation bestimmte Top-Level-Domains vorschreibt. Die Migration ist komplex und erfordert eine sorgfältige Verwaltung von HTTP-Weiterleitungen und eine umfangreiche Korrektur von Legacy-Konfigurationen für ursprungsübergreifende Anfragen.

Fazit

Um die Identitätskontinuität zu erreichen, müssen Sie von Ad-hoc-Anmeldeintegrationen zu etablierten Authentifizierungsstandards wechseln. Wenn Sie geschäftliche Einschränkungen anhand dieser etablierten Verfahren bewerten, z. B. Verbund, Domainkonsolidierung, iFrames oder Metadaten, können Sie UX-Reibungspunkte beseitigen und die Authentifizierung in Ihrem Ökosystem verbessern.

Folgen Sie unserem Blog und sehen Sie sich weitere Ressourcen im Chrome-Identitätsportal an, um mehr über verwandte Themen zu erfahren.