Foederierter Login wandert in den Browser
Federated Credential Management, meist FedCM genannt, ist eine Webplattform-API fuer die Anmeldung mit einem Identity Provider, ohne sich auf Third-Party-Cookies oder redirect-lastige Abläufe zu verlassen. Der W3C First Public Working Draft beschreibt FedCM als datenschutzfreundliche Moeglichkeit, Nutzer mit foederierten Konten einzuloggen, und Browser-Dokumentation behandelt das Thema inzwischen als konkrete Migration fuer Produktteams.
Fuer Kundenportale ist das wichtig, weil Login oft der erste Vertrauensmoment im Produkt ist. Viele Portale nutzen Google Sign-in, Enterprise Identity Provider, Social Login, eingebettete Widgets oder stille Session-Pruefungen, die urspruenglich rund um Third-Party-Cookie-Verhalten gebaut wurden. FedCM nimmt Architekturarbeit nicht weg, verschiebt aber Nutzerprompt, Kontoauswahl und Browserberechtigungen an eine neue Stelle.
Zuerst alle Login-Abhaengigkeiten kartieren
Ein guter FedCM-Plan beginnt mit einem Authentifizierungsinventar, nicht mit einem Library-Upgrade. Produkt und Engineering sollten wissen, welche Provider genutzt werden, welche Seiten One Tap oder Login-Buttons ausloesen, welche Flows in iframes laufen, welche Domains als Relying Parties auftreten und welche Bereiche stille Session-Aktualisierung erwarten.
Diese Pruefung ist besonders wichtig fuer Portale mit mehreren Subdomains, White-Label-Tenants oder eingebetteten Account-Bereichen. FedCM-Support haengt vom Identity Provider und der Browseroberflaeche ab. Eine Relying Party kann die API also nicht einfach allein aktivieren und davon ausgehen, dass jeder Nutzerpfad abgedeckt ist.
- Jeden Identity Provider, jedes SDK, jeden Callback-Endpunkt und jeden Login-Einstieg listen.
- Flows markieren, die Third-Party-Cookies, versteckte iframes, personalisierte Buttons oder Silent Refresh nutzen.
- Top-Level-Login-Seiten von eingebetteten Login-Erlebnissen trennen.
- Pruefen, ob der Identity Provider FedCM-Migrationshinweise fuer Relying Parties veroeffentlicht.
- Den bestehenden Nicht-FedCM-Login behalten, bis Browser- und Provider-Abdeckung belegt ist.
Um browservermittelte Zustimmung herum gestalten
FedCM verschiebt wichtige Teile des Anmeldemoments in Browser-UI. Das ist gut fuer Datenschutz und Konsistenz, bedeutet aber, dass das Produkt Prompt-Position, Anzeige-Callbacks und jeden Grund fuer einen uebersprungenen Prompt nicht mehr voll kontrolliert. Die Google-Identity-Services-Dokumentation beschreibt geaendertes Auto-Sign-in-Verhalten, entfernte Detailmeldungen und vom Browser verwaltete Prompts.
Die Produktoberflaeche sollte Nutzer deshalb vorbereiten, bevor der Browserprompt erscheint. Login-Texte sollten Aufgabe, Provider und erwartetes Ergebnis erklaeren, ohne so zu tun, als gehoere der ganze Dialog zur Website. Fuer europaeische Nutzer sollten Teams den FedCM-Anmeldeprompt ausserdem nicht als pauschale Zustimmung fuer andere Datenverarbeitung behandeln.
iframes und CSP als Launch-Blocker behandeln
FedCM kann in iframes funktionieren, aber die Einbettungskette muss es erlauben. MDN dokumentiert die `identity-credentials-get` Permissions Policy, und die Google-Identity-Services-Migration weist darauf hin, dass bei cross-origin One Tap oder Button Flows `allow="identity-credentials-get"` in den Parent-iframes gesetzt werden muss.
Security Header brauchen dieselbe Aufmerksamkeit. Eine strenge Content Security Policy kann FedCM-Netzwerkanfragen oder Provider-Skripte blockieren. Damit wird die FedCM-Migration zugleich Authentifizierungsarbeit und Plattform-Haertung: Berechtigungen, CSP, Callback-Domains, Testumgebungen und Error Logging gehoeren gemeinsam geprueft.
Login-Konversion ohne alte Callback-Abhaengigkeit messen
Teams achten meist auf Login-Konversion, Kontoerstellung, abgebrochene Anmeldeversuche und Support-Tickets. FedCM kann die Sichtbarkeit alter Prompt-Zustaende veraendern. Analytics sollte deshalb auf Produkt-Events setzen, die das Portal kontrolliert: Login-Screen gesehen, Provider gewaehlt, Credential erhalten, Backend-Session erstellt, Abbruch behandelt und Fallback abgeschlossen.
So bleibt Messung nuetzlich, auch wenn Browser-UI je nach Anbieter oder Version anders wirkt. Das Ziel ist nicht, jeden frueheren Callback nachzubauen. Entscheidend ist, ob Nutzer weiter ins Portal kommen, nach abgebrochenen Prompts sauber zurueckfinden und bei fehlendem FedCM-Support einen anderen Login-Pfad nutzen koennen.
Einen Fallback bauen, dem Nutzer vertrauen
MDN markiert FedCM weiterhin als eingeschraenkt verfuegbar, weil die API nicht in allen weit verbreiteten Browsern funktioniert. Auch die Chrome-Dokumentation empfiehlt Relying Parties, bestehende Nicht-FedCM-Loesungen fuer Nutzer auf nicht unterstuetzten Browsern beizubehalten. Fallback-Design ist damit Kernanforderung und kein nachtraeglicher Notausgang.
Ein guter Fallback ist sichtbar, ruhig und fuer echte Arbeit gleichwertig genug. Nutzer sollten mit klassischem Redirect-Login, E-Mail-Link, Passkey, Enterprise-SSO oder Support-gestuetzter Wiederherstellung weiterkommen, statt eine vage technische Fehlermeldung zu sehen. Der Fallback sollte auf Browsern, Private Modes und verwalteten Geraeten getestet werden, bei denen Third-Party-Cookie-Verhalten abweichen kann.
Ein praktischer FedCM-Rollout fuer Portale
Fuer EDS Labs Webplattform-Projekte ist ein starker FedCM-Rollout gestuft. Zuerst Login-Architektur auditieren, Provider-Support bestaetigen, SDK-Flags aktualisieren, noetige iframe-Berechtigungen setzen, CSP pruefen, produktkontrollierte Login-Events instrumentieren und browservermittelte Prompts gegen echte Portal-Layouts testen.
Danach startet der Rollout hinter einem engen Kompatibilitaets-Gate mit klaren Support-Hinweisen und Rollback. Das Ergebnis ist nicht nur ein neuerer Login-Button. Es ist ein Kundenportal-Login, der weniger von fragilen Third-Party-Cookie-Annahmen abhaengt, Nutzern besser erklaert werden kann und auf datenschutzorientierte Browseraenderungen vorbereitet ist.