Nahtlose und private Nutzerauthentifizierung mit FedCM: Der Ansatz von Seznam

Veröffentlicht am 8. September 2025

Branchenführer in verschiedenen Sektoren wissen, wie wichtig es ist, die Privatsphäre zu schützen und gleichzeitig eine hervorragende Nutzererfahrung zu bieten. Seznam legt großen Wert auf eine kompromisslose Nutzererfahrung und den Datenschutz und hat Federated Credential Management (FedCM) erfolgreich implementiert.

Unternehmen, die von FedCM profitieren

Organisationen aus verschiedenen Bereichen integrieren FedCM in ihre Lösungen. Da FedCM für die föderierte Identitätsverwaltung entwickelt wurde, sind Identitätsanbieter (IdPs) die Hauptnutzer. Sie verwenden es, um die Anmeldung zu verbessern. Auch E-Commerce-Dienstleister und Zahlungsanbieter, von denen viele auch als Identitätsanbieter fungieren, sehen Möglichkeiten, die Nutzererfahrung durch FedCM zu verbessern.

Seznam

Seznam ist ein europäisches Technologieunternehmen und Identitätsanbieter, das 90% der tschechischen Bevölkerung erreicht. Es dient als Social-, Wissens- und Content-Hub. Seznam hat FedCM eingeführt, damit sich Kunden von Onlineshops, die auf den Plattformen der Partner betrieben werden, mit ihrem Seznam-Konto anmelden können.

FedCM-Dialog auf eshop.starkl.com, in dem ein Nutzer aufgefordert wird, sich mit seinem Seznam-Konto anzumelden.
FedCM-Dialog, in dem ein Nutzer aufgefordert wird, sich auf der Website eines Partners mit Seznam anzumelden.

Mit FedCM konnte Seznam die Anmelderaten von Nutzern in Partnernetzwerken deutlich steigern, die Nutzererfahrung verbessern und einen einheitlichen Identitätsfluss unabhängig von der Verfügbarkeit von Drittanbieter-Cookies erzielen.

Motivation

Seznam hat sich aus mehreren Gründen für die Implementierung von FedCM entschieden:

  • FedCM wurde mit Blick auf den Endnutzer entwickelt und gibt Nutzern die Kontrolle über die Informationen, die dem IdP zur Verfügung gestellt werden. Das entspricht der Vision von Seznam, eine sichere und private Umgebung für seine Nutzer zu schaffen.
  • FedCM ist eine integrierte Browserfunktion und mit der bestehenden Anmeldeoberfläche von Seznam kompatibel, die den OAuth 2.0-Standard verwendet.
  • FedCM ist ein datenschutzorientierter Ansatz für die Identitätsföderation. So wird der Besuch des Nutzers bei der vertrauenden Partei (Relying Party, RP) nur dann an den IdP weitergegeben, wenn sich der Nutzer anmeldet. Das entspricht der Ansicht von Seznam zu nachhaltigem Wirtschaften.

Implementierungsdetails

Seznam hat FedCM als Ebene über der bestehenden OAuth-Lösung implementiert. In dieser Architektur überträgt der FedCM-Ablauf einen OAuth-Autorisierungscode sicher vom IdP an die RPs.

FedCM-Ablauf, bei dem das FedCM-Token auf der IdP-Seite gegen einen OAuth-Autorisierungscode ausgetauscht wird
FedCM-Ablauf, der in OAuth integriert ist. Diagrammcode ansehen.

Implementierungsaufwand

Seznam empfand die FedCM-Implementierung als unkompliziert und passend zum bestehenden Ansatz. Die Recherche und API-Implementierung dauerte einen Monat und erforderte zwei Entwickler. Es dauerte weniger als zwei Monate, bis FedCM in der Produktion eingesetzt werden konnte. Der Prozess war iterativ und es wurde viel Zeit für die Untersuchung der API aufgewendet.

Herausforderungen

Als Early Adopter hat Seznam mehrere Herausforderungen identifiziert und wertvolles Feedback gegeben, das zur Weiterentwicklung der API beigetragen hat.

Unterstützung für mehrere Identitätsanbieter

Seznam war an der Unterstützung von FedCM für mehrere Identitätsanbieter interessiert. Mit dieser Funktion sollten Nutzer auf Partner-RPs zwischen Seznam- oder Google-Konten wählen können. Als Seznam jedoch mit der FedCM-Implementierung begann, befand sich die Funktion in einer frühen Implementierungsphase. Entwickler mussten sich für einen Ursprungstest registrieren und ein Token verwenden, um die Funktion für Nutzer zu aktivieren. Aus diesem Grund hat Seznam gewartet, bis die Funktion in Chrome Stable ausgeliefert wurde.

Die Funktion ist ab Chrome 136 verfügbar und Entwickler können die Unterstützung für mehrere Identitätsanbieter konfigurieren. Wenn beispielsweise sowohl Seznam- als auch Google-Identitätsanbieter unterstützt werden sollen, kann der IdP die beiden Anbieter in einen einzigen get()-Aufruf einbeziehen. Die RP kann dies unabhängig tun:

  // Executed on the RP's side:
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // IdP1: Seznam config file URL
            configURL: 'https://szn.cz/.well-known/web-identity',
            clientId: '123',
          },
          {
            // Allow Google Sign-in
            configURL: 'https://accounts.google.com/gsi/fedcm.json',
            clientId: '456',
          },
        ],
      },
    });

Seznam gibt an, dass diese Funktion Teil der Lösung sein wird. Außerdem implementiert das FedCM-Team die Unterstützung für mehrere SDKs, einschließlich der Unterstützung für mehrere Aufrufe.get()

Privates DNS

Seznam ist in der Testphase auf eine Herausforderung im Zusammenhang mit der Netzwerkkonfiguration gestoßen. Der Test-IdP-Server befand sich in einem privaten Netzwerk, auf das nur über privates DNS zugegriffen werden konnte. Diese Einrichtung ist für interne Test- und Entwicklungsumgebungen üblich, bevor sie öffentlich zugänglich gemacht werden.

Diese Einrichtung führt jedoch zu einer Herausforderung: Da eine well-known-Datei von einer eTLD+1 bereitgestellt werden muss und eine private Entwicklungsdomain nicht in der Liste der öffentlichen Suffixe registriert ist, sendet der Browser keine Anfragen zum Abrufen der well-known-Datei, die auf der Entwicklungsdomain gehostet wird:

  • login.idp.example: Beispiel für eine Produktionsdomain.
  • idp.example/.well-known/web-identity: Beispiel für eine well-known-Datei in der Produktion.
  • login.dev.idp.example: Beispiel für eine Entwicklungsdomain.
  • login.dev.idp.example/.well-known/web-identity: Beispiel für eine well-known-Datei in der Entwicklungsumgebung.

Wenn die FedCM-Implementierung auf einer privaten Domain gehostet wird, führen Browseranfragen an die well-known-Datei zu diesem Fehler:

The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED

Sie können diesen Fehler beheben, indem Sie das Chrome-Flag #fedcm-without-well-known-enforcement aktivieren. Wenn dieses Flag aktiviert ist, überspringt der Browser das Abrufen der well-known-Datei zu Testzwecken. Informationen zum Aktivieren von Testflags in Chrome

Benutzerdefinierte Offenlegung von Informationen

Seznam wollte neben dem ursprünglichen FedCM-UI-Design auch zusätzliche Informationen einbeziehen. Im Standard-FedCM-Dialog wird dem Nutzer eine feste Nachricht angezeigt, in der darauf hingewiesen wird, dass bestimmte Daten – in der Regel das Profilbild, der Name und die E-Mail-Adresse des Nutzers – an die RP weitergegeben werden.

Das FedCM-Team hat Feedback eingearbeitet und die API erweitert, um die Anpassung der Offenlegung für den Nutzer zu ermöglichen. Mit der Funktion „Weiter“ kann der IdP den Nutzer beispielsweise auf eine benutzerdefinierte Seite weiterleiten, um zusätzliche Informationen oder Berechtigungen anzufordern. Benutzerdefinierte Parameter und Felder, die ab Chrome 132 unterstützt werden, ermöglichen weitere Anpassungen.

Auf der IdP-Seite wird angezeigt, dass ein Nutzer zusätzliche Berechtigungen gewähren muss, um die FedCM-Registrierung fortzusetzen, z. B. zum Ansehen und Herunterladen von Drive-Dateien und Kalenderterminen.
Der Nutzer kann zusätzliche Berechtigungen prüfen und erteilen, die von der RP an den ID-Bestätigungsendpunkt mit der `Parameters` API übergeben werden.

Ursprungsvalidierung der vertrauenden Partei

Der IdP-Server muss den HTTP-Header Origin in einer eingehenden FedCM-Anfrage validieren, um sicherzustellen, dass die Anfrage mit dem Ursprung übereinstimmt, den die RP zuvor beim IdP registriert hat. So wird sichergestellt, dass die FedCM ID-Bestätigungsanfrage von einer autorisierten RP stammt und nicht von einem Angreifer, der client_id verwendet.

Seznam hat einen Sonderfall: Wenn sich die Partner-RPs bei Seznam registrieren, werden keine Ursprungsdaten der RP angefordert. Das bedeutet, dass der Ursprung der RP nicht überprüft werden kann.

Die FedCM-Integration von Seznam basiert auf einer bestehenden OAuth-Lösung. Es wurde ein alternativer Weg gewählt, bei dem sowohl die client_id als auch das client_secret der RP validiert werden, um die Sicherheit der Lösung zu gewährleisten, ohne den Ursprung zu überprüfen.

Nutzerorientierte Domain des Identitätsanbieters

Die Nutzerauthentifizierungsinfrastruktur von Seznam wird hauptsächlich auf der Domain szn.cz betrieben, auf der die erforderlichen IdP-Endpunkte für FedCM gehostet werden. Die Hauptmarke und die Domain, unter der Nutzer die Dienste von Seznam allgemein kennen und ihnen vertrauen, ist jedoch seznam.cz.

Im FedCM-Dialog wird die tatsächliche Ursprungsdomain der IdP-Endpunkte angezeigt: szn.cz. Nutzer, die mit der Marke seznam.cz vertraut sind, könnten verwirrt sein und zögern, wenn sie während der Anmeldung aufgefordert werden, sich mit der weniger bekannten Domain szn.cz anzumelden.

Ab Chrome 141 lässt FedCM nicht zu, dass eine andere Domain als die angezeigt wird, auf der die IdP-Implementierung gehostet wird. Diese Einschränkung ist eine bewusste Designentscheidung, die die Transparenz für die Nutzer gewährleisten soll. Das FedCM-Team ist sich jedoch der Herausforderungen bewusst, die diese Einschränkung mit sich bringen kann, und diskutiert mögliche Anpassungen.

Auswirkungen

Mit der FedCM API kann Seznam Partnernutzern jetzt Autorisierungsabläufe mit einem einzigen Tippen anbieten. Das Unternehmen hat die Vorteile der FedCM-Nutzererfahrung im Vergleich zu anderen Authentifizierungsmethoden hervorgehoben.

Seznam hat zwar einen deutlichen Anstieg der Nutzerinteraktionen auf Websites festgestellt, die auf die FedCM-Anmeldung umgestellt haben, aber keine umfassende Analyse durchgeführt, um die genauen direkten Auswirkungen von anderen Faktoren zu isolieren. Vor der FedCM-Integration waren Gast-Check-outs möglich, bei denen zugestimmte gehashte E-Mail-Adressen zur Nutzeridentifizierung verwendet wurden. Die Herausforderung bei einer solchen Analyse bestand darin, abzuschätzen, ob eine Nutzerconversion auf FedCM zurückzuführen ist oder ob der Nutzer einen Kauf über den Gast-Check-out abgeschlossen hätte. Die Hypothese von Seznam ist, dass die verbesserte Benutzerfreundlichkeit von FedCM zu dieser höheren Conversion-Rate beigetragen haben könnte.

Fazit

Seznam hat FedCM erfolgreich implementiert und bietet neben der bestehenden OAuth-Lösung einen alternativen Autorisierungsablauf an. Seznam stand vor einigen Herausforderungen im Zusammenhang mit der Unterstützung von Identitätsanbietern, privaten DNS-Einrichtungen, der Anpassung des Offenlegungstexts, der Ursprungsvalidierung der vertrauenden Partei und der Anzeige der nutzerorientierten Domain. Die API hat sich jedoch seit ihrer Implementierung weiterentwickelt. Das FedCM-Team hat Feedback von Seznam und anderen Early Adoptern eingearbeitet und bessere Tools zur Bewältigung dieser Herausforderungen entwickelt. Als Nächstes plant Seznam, die Unterstützung von FedCM für mehrere Identitätsanbieter zu implementieren.