News
FedCM vs Third-Party Cookies for Federated Login
October 27, 2023
FedCM vs third-party cookies for federated login is two ways a site can recognize a user who already has an account at an identity provider. Unpartitioned third-party cookies let an IdP iframe or redirect see a shared jar across sites — the old SSO and tracking model. Federated Credential Management (FedCM) is a browser API that shows a mediated account chooser so the relying party can get an identity assertion without that shared cookie. Neither is access control. A brochure with no Sign in can skip both. RoastMyOpsec does not click Sign in, does not call navigator.credentials, and does not score missing FedCM as an F. It may still grade cookie flags and login-path discoverability on the URL you paste.
The practical difference
A third-party cookie is a silent jar. FedCM is an explicit prompt the browser owns. WebAuthn is a device-bound key for the relying party itself, not a federated IdP. Topics is ads, not login. Related Website Sets is a domain group, not an identity protocol.
Keeping unpartitioned IdP cookies 'until FedCM works everywhere' still ships the old tracking surface.
How to choose a login plan
No login: skip FedCM and skip third-party cookies. First-party password or passkey on your origin: WebAuthn plus rate limits; no FedCM required. Must offer Google/Apple/GitHub: prefer FedCM or documented OAuth redirects over unpartitioned IdP cookies. Permissions-Policy can restrict identity-credentials-get if you do not participate.
| Channel | What it shares | Brochure default | Takeaway |
|---|---|---|---|
| Unpartitioned third-party cookie | Cross-site identity | Avoid | SSO and tracking cost |
| FedCM | Mediated account chooser | Skip unless you federate | Not a roast F if missing |
| WebAuthn passkeys | Device-bound first-party key | If you have a login | See WebAuthn vs passwords |
| OAuth redirect | Code on your origin | Usual federated win | Still HTTPS and CSRF-defend |
When FedCM still wins
FedCM wins when you already federate login and a privacy review wants the browser in the middle. First-party passkeys still win for a site that owns the account. Missing FedCM is healthy. Pair with rate limits vs CAPTCHA if the login is still a password field.
What the roast can prove
Cookie flags and known login paths can surface. FedCM participation is not scored. Confirm Identity Provider well-known files and Permissions-Policy yourself. Pair with consent-based scanning — do not roast someone else's IdP as research.
Common mistakes
The first mistake is keeping unpartitioned IdP cookies as a 'fallback' after adding FedCM.
The second mistake is treating FedCM as a WAF or as MFA.
The third mistake is requiring FedCM as an OPSEC finding on a brochure.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is missing FedCM a vulnerability?
- No. It is a federated-login choice. Missing it is not a roast F.
- Does FedCM replace WebAuthn?
- No. FedCM is a mediated IdP chooser. WebAuthn is a first-party authenticator. Many sites want neither.
- Does RoastMyOpsec call the FedCM API?
- No. It does not run identity ceremonies. It may still grade cookies and login-path discoverability.