Nahtlose und private Nutzerauthentifizierung mit FedCM: Der Ansatz von Seznam

Natalia Markoborodova
Natalia Markoborodova

Veröffentlicht: 8. September 2025

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

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 (Identity Providers, IdPs) die Hauptnutzer. Sie verwenden es, um die Anmeldung zu verbessern. E-Commerce-Dienstleister und Zahlungsanbieter, von denen viele auch als Identitätsanbieter fungieren, sehen ebenfalls Möglichkeiten, die Nutzerfreundlichkeit durch FedCM zu verbessern.

Seznam

Seznam ist ein europäisches Technologieunternehmen und Identitätsanbieter, das 90% der tschechischen Bevölkerung erreicht. Sie dient als Hub für soziale Interaktionen, Wissen und Inhalte. 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-Dialogfeld, in dem ein Nutzer aufgefordert wird, sich auf der Website eines Partners mit Seznam anzumelden.

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

Motivation

Seznam hat sich für die Implementierung von FedCM entschieden, da es mehrere anerkannte Vorteile bietet:

  • FedCM wurde mit Blick auf den Endnutzer entwickelt und gibt Nutzern die Kontrolle über die Informationen, die dem Identitätsanbieter zur Verfügung gestellt werden. Dies entspricht der Vision von Seznam, seinen Nutzern eine sichere und private Umgebung zu bieten.
  • FedCM ist eine integrierte Browserfunktion und mit der bestehenden Anmeldefunktion von Seznam kompatibel, die den OAuth 2.0-Standard verwendet.
  • FedCM ist ein datenschutzorientierter Ansatz für die Identitätsföderation. Der Besuch des Nutzers bei der vertrauenden Partei (Relying Party, RP) wird beispielsweise nur mit dem Identitätsanbieter (Identity Provider, IdP) geteilt, wenn sich der Nutzer anmeldet. Das entspricht der Ansicht von Seznam zu nachhaltigen Unternehmen.

Implementierungsdetails

Seznam hat FedCM als zusätzliche Ebene für die bestehende OAuth-Lösung implementiert. In dieser Architektur wird ein OAuth-Autorisierungscode sicher vom IdP an die RPs übertragen.

FedCM-Ablauf, bei dem das FedCM-Token auf der IdP-Seite gegen einen OAuth-Autorisierungscode ausgetauscht wird
FedCM-Ablauf mit OAuth-Integration. Diagrammcode

Implementierungsaufwand

Seznam fand die FedCM-Implementierung unkompliziert und im Einklang mit dem 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 erkannt und wertvolles Feedback gegeben, das zur Weiterentwicklung der API beigetragen hat.

Unterstützung mehrerer Identitätsanbieter

Seznam war an der Unterstützung mehrerer Identitätsanbieter durch FedCM interessiert. Mit dieser Funktion sollten Nutzer auf Partner-RPs zwischen Seznam- und Google-Konten wählen können. Als Seznam mit der FedCM-Implementierung begann, befand sich die Funktion jedoch 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 eingeführt 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 als Identitätsanbieter unterstützt werden sollen, kann der IdP die beiden Anbieter in einen einzelnen get()-Aufruf einbeziehen. Der 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 seiner Lösung sein wird. Außerdem implementiert das FedCM-Team die Unterstützung mehrerer SDKs mit Unterstützung für mehrere get()-Aufrufe.

Privates DNS

Bei Seznam ist während der Testphase ein Problem mit der Netzwerkkonfiguration aufgetreten. Der Test-IdP-Server befand sich in einem privaten Netzwerk, auf das nur über privates DNS zugegriffen werden konnte. Diese Einrichtung ist vor der öffentlichen Nutzung in der Regel für interne Tests und Entwicklungsumgebungen vorgesehen.

Diese Einrichtung führt jedoch zu einem Problem: Da eine well-known-Datei von einer eTLD+1 bereitgestellt werden muss und eine private Entwicklungsdomain nicht in der öffentlichen Suffixliste 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 die 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 die Datei well-known in der Entwicklungsumgebung.

Wenn die FedCM-Implementierung auf einer privaten Domain gehostet wird, führen Browseranfragen an die Datei well-known 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, ruft der Browser die Datei well-known zu Testzwecken nicht ab. Informationen zum Aktivieren von Test-Flags in Chrome

Benutzerdefinierte Offenlegung von Informationen

Seznam wollte neben dem ursprünglichen FedCM-UI-Design auch zusätzliche Informationen einfügen. Im Standard-FedCM-Dialogfeld wird dem Nutzer eine feste Meldung angezeigt, in der angegeben wird, dass bestimmte Daten – in der Regel das Profilbild, der Name und die E-Mail-Adresse des Nutzers – mit dem RP geteilt werden.

Das FedCM-Team hat Feedback berücksichtigt und die API erweitert, um die Anpassung der Offenlegung zu ermöglichen, die dem Nutzer präsentiert wird. Mit der Continue on-Funktion kann der IdP den Nutzer beispielsweise auf eine benutzerdefinierte Seite weiterleiten, um zusätzliche Informationen oder Berechtigungen anzufordern. Mit den Funktionen Benutzerdefinierte Parameter und Felder, die ab Chrome 132 unterstützt werden, sind weitere Anpassungen möglich.

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, die vom RP an den ID-Assertion-Endpunkt übergeben werden, mit der Parameters API prüfen und gewähren.

Ursprungsvalidierung der vertrauenden Seite

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

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

Die FedCM-Integration von Seznam basiert auf einer bestehenden OAuth-Lösung. Es wurde der alternative Pfad gewählt, bei dem sowohl client_id als auch client_secret des RP validiert wurden, um sicherzustellen, dass die Lösung sicher bleibt, ohne den Ursprung zu prüfen.

Nutzerorientierte Domain des Identitätsanbieters

Die Infrastruktur für die Nutzerauthentifizierung von Seznam wird hauptsächlich in der Domain szn.cz betrieben, in der die erforderlichen IdP-Endpunkte für FedCM gehostet werden. Die Hauptidentität des Unternehmens und die Domain, unter der Nutzer seine Dienste allgemein erkennen und ihnen vertrauen, ist jedoch seznam.cz.

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

Ab Chrome 141 darf bei FedCM keine andere Domain als die angezeigt werden, auf der die IdP-Implementierung gehostet wird. Diese Einschränkung ist eine bewusste Designentscheidung, die für mehr Transparenz für die Nutzer sorgen 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 nur einem Tippen anbieten. Darin wurden die Vorteile der FedCM-Benutzerfreundlichkeit im Vergleich zu anderen Authentifizierungsmethoden hervorgehoben.

Seznam hat zwar einen deutlichen Anstieg des Nutzerengagements auf Websites festgestellt, die auf die FedCM-Anmeldung umgestellt wurden, aber keine umfassende Analyse durchgeführt, um die genauen direkten Auswirkungen von anderen Faktoren zu isolieren. Vor der FedCM-Integration war es bei der Implementierung möglich, Gast-Check-outs mit gehashten E-Mail-Adressen durchzuführen, für die eine Einwilligung vorlag, um Nutzer zu identifizieren. Die Herausforderung bei einer solchen Analyse bestand darin, abzuschätzen, ob eine Nutzer-Conversion auf FedCM zurückzuführen ist oder ob der Nutzer den Kauf über die Gastabrechnung abgeschlossen hätte. Die Hypothese von Seznam besagt, dass die verbesserte Benutzerfreundlichkeit von FedCM zu dieser höheren Conversion-Rate beigetragen haben könnte.

Fazit

Seznam hat FedCM erfolgreich implementiert und bietet damit neben der bestehenden OAuth-Lösung einen alternativen Autorisierungsablauf. Seznam hatte einige Herausforderungen im Zusammenhang mit der Unterstützung von Identitätsanbietern, privaten DNS-Einrichtungen, der Anpassung des Offenlegungstexts, der Validierung des Ursprungs der vertrauenden Partei und der nutzerorientierten Domänenanzeige. Die API hat sich seit ihrer Implementierung jedoch weiterentwickelt. Das FedCM-Team hat Feedback von Seznam und anderen Early Adopters berücksichtigt und so 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.