Nahtlose und private Nutzerauthentifizierung mit FedCM: Implementierung von Seznam

Branchenführer in verschiedenen Sektoren wissen, wie wichtig es ist, die Privatsphäre zu schützen und gleichzeitig allen Nutzern eine optimale Erfahrung zu bieten. Seznam, das sich für eine kompromisslose Nutzerfreundlichkeit und den Datenschutz einsetzt, hat Federated Credential Management (FedCM) erfolgreich integriert.

Zielprofile: Unternehmen, die von FedCM profitieren

Organisationen aus verschiedenen Bereichen haben FedCM in ihre Lösungen integriert. Da FedCM für die föderierte Identitätsverwaltung konzipiert ist, sind Identitätsanbieter (Identity Providers, IdPs) die Hauptnutzer. Sie verwenden FedCM, um eine verbesserte Anmeldung zu ermöglichen. E-Commerce-Dienstleister und Zahlungsanbieter, von denen viele auch als Identitätsanbieter fungieren, haben ebenfalls Möglichkeiten zur Verbesserung der Nutzerfreundlichkeit durch die Implementierung von FedCM erkannt.

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.

Das FedCM-Dialogfeld wird auf eshop.starkl.com angezeigt und der Nutzer wird aufgefordert, sich mit seinem Seznam-Konto anzumelden.
FedCM-Dialogfeld, in dem der Nutzer aufgefordert wird, sich auf der Website des Partners mit Seznam anzumelden.

Mit FedCM konnte Seznam die Anmelderaten der Nutzer in den Netzwerken seiner Partner deutlich steigern. Außerdem wurde die Nutzerfreundlichkeit verbessert und ein einheitlicher Identitätsfluss unabhängig von der Verfügbarkeit von Drittanbieter-Cookies erreicht.

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 ihm die Kontrolle über die Informationen, die dem Identitätsanbieter zur Verfügung gestellt werden. Dies entspricht der Vision von Seznam, eine sichere und private Umgebung für seine Nutzer zu schaffen.
  • FedCM ist eine integrierte Browserfunktion, die mit der bestehenden Anmeldefunktion von Seznam kompatibel ist, die den OAuth 2.0-Standard verwendet.
  • FedCM ist ein datenschutzorientierter Ansatz für die Identitätsföderation. Beispiel: Die Tatsache, dass der Nutzer die vertrauende Partei (Relying Party, RP) besucht hat, wird nur dann an den Identitätsanbieter (Identity Provider, IdP) weitergegeben, wenn der Nutzer sich anmeldet. Das entspricht der Ansicht von Seznam zu nachhaltigen Unternehmen.

Implementierungsdetails

Seznam hat FedCM als zusätzliche Ebene über der vorhandenen OAuth-Lösung implementiert. In dieser Architektur wird der FedCM-Ablauf verwendet, um einen OAuth-Autorisierungscode sicher vom IdP an die RPs zu übertragen.

Ein Sequenzdiagramm, das den FedCM-Ablauf zeigt, bei dem das FedCM-Token auf der IdP-Seite gegen einen OAuth-Autorisierungscode ausgetauscht wird
FedCM-Ablauf mit OAuth-Integration. Code des Diagramms

Implementierungsaufwand

Seznam hob hervor, dass die Implementierung von FedCM unkompliziert war und sich an ihrem bestehenden Ansatz orientierte. Die Recherche und Implementierung der API dauerte einen Monat und erforderte den Einsatz von zwei Entwicklern. Es dauerte weniger als zwei Monate, bis FedCM in der Produktion eingesetzt werden konnte. Der Prozess war iterativ und es wurde viel Zeit darauf verwendet, die API sorgfältig zu untersuchen.

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 den RPs der Partner zwischen Seznam- oder Google-Konten wählen können. Als Seznam jedoch zum ersten Mal an die FedCM-Implementierung herangegangen ist, befand sich die Funktion in einem frühen Implementierungsstadium. Entwickler mussten sich für einen Ursprungstest registrieren und ein Token verwenden, um die Funktion für ihre 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 auch unabhängig tun:

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

Seznam hat angegeben, 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 für interne Test- und Entwicklungsumgebungen üblich, bevor Dienste öffentlich zugänglich gemacht werden.

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 eine bekannte 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 bekannte Datei 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

Dieser Fehler kann behoben werden, 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 teilte außerdem mit, dass sie neben dem ursprünglichen Design der FedCM-Benutzeroberfläche zusätzliche Informationen einfügen möchten. Im Standard-FedCM-Dialogfeld wird dem Nutzer eine feste Meldung angezeigt, in der darauf hingewiesen 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 umleiten, 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 einer IdP-Seite wird angezeigt, dass der Nutzer zusätzliche Berechtigungen gewähren muss, um die FedCM-Registrierung fortzusetzen. In diesem Fall sind das die Berechtigungen 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-Assertionsanfrage von einer autorisierten vertrauenden Seite stammt und nicht von einem Angreifer, der client_id verwendet.

Bei Seznam gibt es einen Grenzfall: Wenn sich die Partner-RPs bei Seznam registrieren, werden die Ursprungsdaten der RPs nicht angefordert. Das bedeutet, dass der Ursprung des Rechtssubjekts nicht bestätigt werden kann.

Die FedCM-Integration von Seznam basiert auf einer vorhandenen OAuth-Lösung. Sie wählten den alternativen Weg, sowohl client_id als auch client_secret des RP zu validieren, um sicherzustellen, dass die Lösung sicher blieb, ohne dass der Ursprung überprüft werden musste.

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. Ihre primäre Unternehmensidentität und die Domain, unter der Nutzer ihre Dienste allgemein erkennen und ihnen vertrauen, ist jedoch seznam.cz.

Im FedCM-Dialogfeld wird die tatsächliche Ursprungsdomain der IdP-Endpunkte angezeigt, in diesem Fall szn.cz. Nutzer, die mit der Marke seznam.cz vertraut sind, könnten verwirrt sein und zögern, wenn sie aufgefordert werden, sich während des Anmeldevorgangs mit der weniger vertrauten Domain szn.cz anzumelden.

Ab Chrome 141 darf mit FedCM keine Domain angezeigt werden, die sich von der Domain unterscheidet, auf der die IdP-Implementierung gehostet wird. Diese Einschränkung ist eine bewusste Designentscheidung, die für Transparenz für den 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 den Nutzern seiner Partner jetzt Autorisierungsabläufe mit nur einem Tippen anbieten. Sie hoben die Vorteile der FedCM-Benutzerfreundlichkeit im Vergleich zu anderen Authentifizierungsmethoden hervor.

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 in der Implementierung möglich, Gastzahlungen mit gehashten E-Mail-Adressen durchzuführen, für die eine Einwilligung zur Nutzeridentifizierung vorlag. 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 deutet darauf hin, 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. Die Entwickler von Seznam hatten 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, um bessere Tools zur Bewältigung dieser Herausforderungen zu entwickeln. Als Nächstes plant Seznam, die Unterstützung von FedCM für mehrere Identitätsanbieter zu implementieren.