“Sign in with Google” and “Continue with Apple” have carried federated login for more than a decade. They strip away onboarding friction, kill password fatigue, and turn anonymous traffic into accounts, which is why they sit on nearly every consumer signup page. The machinery underneath them is the problem.Those buttons run on third-party cookies. The legacy social login flow relies on the exact cross-domain mechanism that privacy regulators have spent years trying to shut down. “The legacy social login flow relies on the exact cross-domain mechanism that privacy regulators have spent years trying to shut down.”Safari has blocked third-party cookies by default since 2020 (Intelligent Tracking Prevention) and Firefox since 2019 (Enhanced Tracking Protection), which already puts roughly half the web in a cookieless state. Chrome is the messier story: Google walked back its forced deprecation in 2024 and moved to a user-choice model instead of flipping a switch, so the “cookie-pocalypse” deadline everyone built roadmaps around never actually arrived. Do not read that as a reprieve. Two major engines are blocked by default; Chrome’s Incognito is blocked by default; ad blockers and consent fatigue keep climbing; and the cookie is eroding by attrition, whether or not anyone announces a death date. Any login flow built on it is on borrowed time.FedCM (Federated Credential Management) is the standard built to keep federated login working once that mechanism is gone. The W3C and the major browser engines developed it as a browser-native API that runs federated identity flows without cross-site tracking.How it actually worksThe shift is architectural. In a legacy flow, clicking a social button fires hidden iframes, redirects, or pop-ups so the identity provider can read its own cookies and confirm who you are. That same channel lets the IdP track you across the web. FedCM puts the browser in the middle as a trusted mediator. The site asks for an identity token through one explicit API call, navigator.credentials.get(), and the browser runs the rest:The site requests an identity token from the browser.The browser fetches account details from a config file hosted by the IdP, kept siloed from the site making the request.The browser shows a native sign-in prompt instead of a pop-up.On explicit user consent, the browser passes a token back to the site’s backend to create a session.Authentication and passive tracking get decoupled. (More on the API: the FedCM spec and MDN docs.)It also fixes the NASCAR problem. Years of bolting on every available social login produced signup pages plastered with competing brand buttons, the registration equivalent of a stock car covered in sponsor decals. That is cognitive load, and cognitive load costs conversions. “FedCM skips the wall of buttons and surfaces the right account in a single native prompt.”Because the browser already knows which provider you used last, FedCM skips the wall of buttons and surfaces the right account in a single native prompt.Legacy flow vs. FedCMLegacy federated flowFedCMMechanismHidden iframes, redirects, pop-upsOne browser-mediated API callPrivacy modelDepends on third-party cookiesNo third-party cookies; explicit per-sign-in consentUser experienceRedirect chains, blocked pop-ups, the NASCAR button wallOne-tap native browser promptSecurityPhishable redirect surfacesBrowser-isolated prompt the page can’t spoofThe practical payoff is conversion. Every extra click and every interrupted redirect sheds a percentage of the people trying to sign up, and mobile browsers frequently block the secondary windows legacy flows depend on. A single native prompt removes that drop-off. “Every extra click and every interrupted redirect sheds a percentage of the people trying to sign up, and mobile browsers frequently block the secondary windows legacy flows depend on.”There is a maintenance angle, too: a standardized browser UI means your team stops building and babysitting bespoke login components, and the flow upgrades through browser releases rather than refactors.What this looks like in productionAxel Springer runs FedCM on Ory across hundreds of millions of users. Thomas Bergemann, its General Director of Product & Revenue, put the result plainly: “We see an over 15x increase in registrations.” (Read the case study.)Google’s own testing on browser-mediated sign-in shows the same shape of result: dropping the jarring secondary-window step, the one mobile devices routinely block, cuts user drop-off. Shopify moved onto browser-mediated identity ahead of the cookie changes and held checkout conversion stable on strict, privacy-centric mobile browsers, the exact environments where legacy flows quietly fail.Getting started with OryStep 1: Put the backend behind a CIAM platform. Don’t hand-roll this. Ory Kratos processes the backend side of FedCM natively, turning browser-side identity assertions into secure user sessions. (See the Ory FedCM deployment docs.)Step 2: Configure your social sign-in providers. In the Ory Console, open the Social Sign-In panel, select your IdP, and enter its FedCM Config URL. Back-channel trust verification is handled for you.Step 3: Embed the JavaScript trigger. Drop a lightweight snippet on your login page to detect support and fall back cleanly when it isn’t there:if ('IdentityCredential' in window) { navigator.credentials.get({ identity: { providers: [{ configURL: 'https://auth.your-business.com/self-service/methods/oidc/fedcm/google', clientId: 'YOUR_CLIENT_ID', }] } }).then((credential) => { return fetch('/self-service/methods/oidc/fedcm/login', { method: 'POST', body: JSON.stringify({ token: credential.token }) }); }).catch((err) => { console.error('FedCM flow interrupted, fallback to traditional OIDC:', err); });}If the browser doesn’t support FedCM, the flow falls back to a standard OpenID Connect redirect, so nobody gets locked out mid-migration. Want to test before you wire up a real IdP? There’s a free MockFedCM site for that.Where this leaves youFederated login is moving into the browser, and the privacy model is moving with it. Safari and Firefox already block by default; Chrome is leaking the cookie out the side rather than killing it outright. Neither path leaves your social logins where they were. The teams auditing their auth stack now are the ones who won’t be debugging broken login loops on someone else’s timeline later. Better to make this move on your own schedule than on the browser’s.The post Your social login buttons run on third-party cookies. FedCM doesn’t. appeared first on The New Stack.