Federated login is moving into the browser
Federated Credential Management, usually shortened to FedCM, is a web platform API for signing in with an identity provider without depending on third-party cookies or redirect-heavy flows. The W3C First Public Working Draft defines it as a privacy-preserving way for websites to let users log in with federated accounts, and browser documentation now treats it as a practical migration topic for production teams.
For customer portals, this matters because login is often the first trust moment in the product. Many portals use Google sign-in, enterprise identity providers, social login, embedded widgets or silent session checks that were designed around third-party cookie behavior. FedCM does not remove identity architecture work, but it changes where the user prompt, account choice and browser permissions sit.
Map every federated sign-in dependency first
A good FedCM plan starts with an authentication inventory, not with a library upgrade. Product and engineering teams should know which providers are used, which pages trigger One Tap or sign-in buttons, which flows run inside iframes, which domains act as relying parties and which parts of the app expect silent session refresh.
This audit is especially important for portals with multiple subdomains, white-label tenants or embedded account areas. FedCM support depends on the identity provider and browser surface, so a relying party cannot simply enable the API on its own and assume every user path is covered.
- List every identity provider, SDK, callback endpoint and login entry point.
- Mark flows that depend on third-party cookies, hidden iframes, personalized buttons or silent refresh.
- Separate top-level login pages from embedded login experiences.
- Check whether the identity provider publishes FedCM relying-party migration guidance.
- Keep the existing non-FedCM login path until browser and provider coverage is proven.
Design around browser-mediated consent
FedCM moves important parts of the sign-in moment into browser UI. That is useful for privacy and consistency, but it means the product can no longer fully control prompt placement, display callbacks or every reason a prompt was skipped. Google Identity Services guidance notes that FedCM changes automatic sign-in behavior, removes some detailed moment notifications and lets the browser manage prompts.
The product interface should therefore prepare users before the browser prompt appears. Login copy should explain the task, the provider and the expected result without pretending that the site owns the whole dialog. For European users, teams should also avoid treating the FedCM sign-in prompt as a blanket consent mechanism for unrelated data processing.
Treat iframes and CSP as launch blockers
FedCM can work inside iframes, but the embedding chain has to allow it. MDN documents the `identity-credentials-get` Permissions Policy, and Google Identity Services migration guidance calls out the need to add `allow="identity-credentials-get"` to parent iframes for cross-origin One Tap or Button flows.
Security headers need the same attention. A strict Content Security Policy can block the FedCM network requests or scripts a provider needs. That makes FedCM migration part authentication work and part platform hardening: permissions, CSP, callback domains, test environments and error logging should be reviewed together.
Measure login conversion without overfitting to old callbacks
Teams usually care about sign-in conversion, account creation, abandoned login attempts and support tickets. FedCM can change the visibility of old prompt states, so analytics should focus on product events the portal controls: login screen viewed, provider selected, credential received, backend session created, cancellation handled and fallback completed.
This keeps the measurement useful even when browser UI differs across vendors or versions. The goal is not to recreate every previous callback. It is to understand whether users can still enter the portal, recover from cancelled prompts and choose another login path when FedCM is unavailable.
Build a fallback path users can trust
MDN still marks FedCM as limited availability because it is not supported across all widely used browsers. Chrome documentation also tells relying parties to keep existing non-FedCM federated identity solutions for users on unsupported browsers. That makes fallback design a core requirement rather than a temporary afterthought.
A good fallback is visible, calm and equivalent enough for real work. Users should be able to continue with a classic redirect login, email link, passkey, enterprise SSO route or support-assisted account recovery without seeing a vague technical error. The fallback should be tested on browsers, private modes and managed devices where third-party cookie behavior may differ.
A practical FedCM rollout plan for portals
For EDS Labs web platform projects, a strong FedCM rollout is staged. First audit the login architecture, confirm provider support, update SDK flags, add iframe permissions where needed, review CSP, instrument product-owned login events and test browser-mediated prompts against real portal layouts.
Then launch behind a narrow compatibility gate with clear support notes and rollback. The result is not merely a newer sign-in button. It is a customer portal login system that is less dependent on fragile third-party-cookie assumptions, easier to explain to users and better prepared for privacy-focused browser changes.