“Continue with…” buttons solve a real problem. One account can open dozens of services without another password to remember. The old implementation, however, often depends on cross-site redirects, embedded frames, and third-party cookies that let an identity provider observe where its users travel.
The Federated Credential Management API, or FedCM, changes that relationship. It places the browser between the website asking for a login and the identity provider holding the account. The goal is not anonymous sign-in. It is a more visible and constrained exchange.
How FedCM browser sign-in works
The FedCM API provides a browser-managed flow for federated identity. A relying party—the site you want to enter—asks the browser for an identity credential from a supported provider. The browser retrieves the available account information and presents its own chooser.
If you select an account, the identity provider issues an assertion for that relying party. The site uses the assertion to sign you in. The browser controls when account information becomes visible and when the two parties learn about the connection.
FedCM is experimental and not supported equally across all browsers. Websites need a fallback. That matters because a button with the same label may use FedCM in one browser and a redirect or popup in another.
Why third-party cookies made sign-in awkward
Traditional federated login often relied on an identity provider's cookie inside another website. The cookie helped the embedded provider recognise that you were already signed in, personalize the button, or refresh a session. It also created a cross-site observation point.
Browsers have increasingly restricted third-party cookies because they support tracking far beyond login. Removing them improves privacy but can break legitimate identity flows. FedCM is an attempt to preserve the useful part without restoring a general cross-site cookie channel.
Our guide to third-party cookies explains the broader mechanism. The important FedCM distinction is that identity exchange moves into a dedicated browser API with explicit rules, not an invisible frame that behaves like ordinary web content.
What each party learns
Before you approve, the relying party should not learn which identity-provider account you hold. The identity provider should not freely learn every relying-party page you visit. The FedCM specification treats that separation as a core privacy objective.
The browser makes different network requests for different purposes. Public configuration can be fetched without identity cookies. Account data is fetched from the provider so the browser can build the chooser, but the design limits the information that request carries about the relying party.
Once you select an account and approve the flow, the boundary changes. The provider and relying party can learn the information needed to connect that identity to the site. FedCM cannot make a federated login unlinkable after you deliberately create the link.
The consent screen deserves attention
The account chooser is not decoration. It is the point where the browser tells you which provider, account, and destination are involved. Read the destination domain, especially when the sign-in button sits inside an unfamiliar page or embedded experience.
A provider may offer profile details such as a name, email address, or avatar as part of account selection. The relying party receives the assertion and whatever account information the agreed flow includes. Its privacy policy still governs what happens after login.
FedCM does not replace passkeys
Federated identity and passkeys solve different problems. FedCM lets one identity provider vouch for you to another site. A passkey authenticates you directly to a specific relying party with a domain-bound cryptographic credential.
Federated sign-in reduces account setup and recovery work. It also creates dependency: if the provider account is suspended or inaccessible, connected services may become harder to reach. A direct account with a passkey avoids that single-provider relationship but requires each service to manage recovery well.
Our guide to browser passkeys covers that model. Neither method is automatically right for every account. The useful choice depends on convenience, recovery, and how much identity linking you accept.
Before using federated sign-in
Check the destination
Confirm the full domain shown by the browser. If the login appears without an action you started, close it and return through the service's main sign-in page.
Choose the account intentionally
People often maintain personal, work, and community identities with the same provider. Selecting the wrong profile can expose a name or email address you did not mean to connect. Slow down at the chooser.
Review connected services
Use the identity provider's account dashboard to review third-party access. Remove services you no longer use. Ending a browser session does not necessarily revoke the relationship at the provider.
Keep recovery independent
Protect the identity-provider account with strong authentication and current recovery options. For important services, add a direct recovery method if the site supports one. A convenient sign-in flow should not leave every door dependent on one key.
A browser-visible identity boundary
FedCM is a thoughtful response to a web transition. Third-party cookies are a poor foundation for identity, yet federated sign-in remains useful. Browser mediation can make the exchange narrower, more legible, and less available for passive tracking.
The plain rule remains strong: know which provider is vouching for you, which site is receiving that identity, and what happens after approval. A browser can protect the handoff. You still decide whether the relationship should exist.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.