Föderierter Login wandert in den Browser
Federated Credential Management, meist FedCM genannt, ist eine Webplattform-API für 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 Möglichkeit, Nutzer mit föderierten Konten einzuloggen, und Browser-Dokumentation behandelt das Thema inzwischen als konkrete Migration für Produktteams.
Für 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-Prüfungen, die ursprünglich 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-Abhängigkeiten 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 auslösen, welche Flows in iframes laufen, welche Domains als Relying Parties auftreten und welche Bereiche stille Session-Aktualisierung erwarten.
Diese Prüfung ist besonders wichtig für Portale mit mehreren Subdomains, White-Label-Tenants oder eingebetteten Account-Bereichen. FedCM-Support hängt vom Identity Provider und der Browseroberfläche 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.
- Prüfen, ob der Identity Provider FedCM-Migrationshinweise für Relying Parties veröffentlicht.
- 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 für Datenschutz und Konsistenz, bedeutet aber, dass das Produkt Prompt-Position, Anzeige-Callbacks und jeden Grund für einen übersprungenen Prompt nicht mehr voll kontrolliert. Die Google-Identity-Services-Dokumentation beschreibt geändertes Auto-Sign-in-Verhalten, entfernte Detailmeldungen und vom Browser verwaltete Prompts.
Die Produktoberfläche sollte Nutzer deshalb vorbereiten, bevor der Browserprompt erscheint. Login-Texte sollten Aufgabe, Provider und erwartetes Ergebnis erklären, ohne so zu tun, als gehöre der ganze Dialog zur Website. Für europäische Nutzer sollten Teams den FedCM-Anmeldeprompt außerdem nicht als pauschale Zustimmung für 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-Härtung: Berechtigungen, CSP, Callback-Domains, Testumgebungen und Error Logging gehören gemeinsam geprüft.
Login-Konversion ohne alte Callback-Abhängigkeit messen
Teams achten meist auf Login-Konversion, Kontoerstellung, abgebrochene Anmeldeversuche und Support-Tickets. FedCM kann die Sichtbarkeit alter Prompt-Zustände verändern. Analytics sollte deshalb auf Produkt-Events setzen, die das Portal kontrolliert: Login-Screen gesehen, Provider gewählt, Credential erhalten, Backend-Session erstellt, Abbruch behandelt und Fallback abgeschlossen.
So bleibt Messung nützlich, auch wenn Browser-UI je nach Anbieter oder Version anders wirkt. Das Ziel ist nicht, jeden früheren Callback nachzubauen. Entscheidend ist, ob Nutzer weiter ins Portal kommen, nach abgebrochenen Prompts sauber zurückfinden und bei fehlendem FedCM-Support einen anderen Login-Pfad nutzen können.
Einen Fallback bauen, dem Nutzer vertrauen
MDN markiert FedCM weiterhin als eingeschränkt verfügbar, weil die API nicht in allen weit verbreiteten Browsern funktioniert. Auch die Chrome-Dokumentation empfiehlt Relying Parties, bestehende Nicht-FedCM-Lösungen für Nutzer auf nicht unterstützten Browsern beizubehalten. Fallback-Design ist damit Kernanforderung und kein nachträglicher Notausgang.
Ein guter Fallback ist sichtbar, ruhig und für echte Arbeit gleichwertig genug. Nutzer sollten mit klassischem Redirect-Login, E-Mail-Link, Passkey, Enterprise-SSO oder Support-gestützter Wiederherstellung weiterkommen, statt eine vage technische Fehlermeldung zu sehen. Der Fallback sollte auf Browsern, Private Modes und verwalteten Geräten getestet werden, bei denen Third-Party-Cookie-Verhalten abweichen kann.
Ein praktischer FedCM-Rollout für Portale
Für EDS Labs Webplattform-Projekte ist ein starker FedCM-Rollout gestuft. Zuerst Login-Architektur auditieren, Provider-Support bestätigen, SDK-Flags aktualisieren, nötige iframe-Berechtigungen setzen, CSP prüfen, produktkontrollierte Login-Events instrumentieren und browservermittelte Prompts gegen echte Portal-Layouts testen.
Danach startet der Rollout hinter einem engen Kompatibilitäts-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 abhängt, Nutzern besser erklärt werden kann und auf datenschutzorientierte Browseränderungen vorbereitet ist.