Chrome 143 changes FedCM: structured ID assertions, stricter client metadata, and breaking API updates

Chrome 143 (published January 12, 2026) introduces several FedCM (Federated Credential Management) changes that are immediately relevant for full‑stack teams building web sign‑in flows. The update lets Identity Providers (IdPs) return structured JSON in the ID assertion, tightens client_metadata validation (the browser will begin enforcing required fields), and makes a few breaking API/shape changes that will be enforced by Chrome 145. (developer.chrome.com)

Why this matters

• These aren’t optional UX tweaks: they change the shape of the data your IdP endpoints return and what Chrome will accept when matching RPs to IdPs. If you host an IdP or rely on FedCM-integrated sign‑in, the change can break logins silently once Chrome 145 rolls in.
• The changes affect both client code (navigator.credentials.get() calls, error handling, and where you include nonce) and server-side endpoints (.well-known/web-identity and the ID assertion response).
• Chrome provides a transition window (Chrome 143–144) where old and new behaviors coexist, but teams must update before enforcement in Chrome 145.

Key technical changes (short)

• ID assertion token can be a structured JSON object instead of a serialized string (e.g., { token: { access_token: "...", user_info: { email: "..."} } }). This removes manual server-side JSON stringification and client-side parsing. (developer.chrome.com)
• client_metadata validation is stricter: if you use a client_metadata endpoint, your .well-known/web-identity must include accounts_endpoint and login_url; Chrome 145 will enforce accounts_endpoint. (developer.chrome.com)
• API shape / error changes: the top‑level nonce is being moved into the params object used with navigator.credentials.get(...), and IdentityCredentialError.code is renamed to IdentityCredentialError.error — handle both during the transition. (developer.chrome.com)

Practical checklist for full‑stack teams (high impact, low friction)

• Update IdP ID assertion responses
  • Return a real JSON object for token (not a JSON string). Add any additional claims under a stable structure (access_token, user_info, etc.).
  • Verify server-side signing/verification logic accepts the structured token format your RP expects.
• Validate and publish well-known metadata
  • Ensure your .well-known/web-identity includes required fields: at minimum accounts_endpoint and login_url.
  • Test endpoint discovery and response shapes in staging using Chrome 143.
• Update client integration
  • Move nonce into the params object passed to navigator.credentials.get({...}). Avoid top‑level nonce.
  • Update error handling to check both e.error and e.code during the 143–144 transition window.
  • Add feature‑detection and graceful fallback for browsers that don’t support the new shapes.
• Test cross‑browser behavior and regressions
  • Run end‑to‑end tests with Chrome 143+ and with older browsers. Use the FedCM demo and implementation guidance in Chrome docs to validate flows. (developer.chrome.com)
• Roll out with telemetry and staged feature flags
  • Deploy server changes behind a toggle, enable for a small percentage of traffic, and monitor auth failure rates and user drop-offs before full rollout.
  • Add logging for discovery, .well-known fetches, and identity assertion parsing errors.
• CI / security pipelines
  • Add a test that fetches .well-known and validates the presence of required client_metadata keys.
  • If you’re an IdP, treat the change as a compatibility breaking change and notify RPs or customers with integration guides.

Timeline and risk

• Transition window: Chrome 143–144 support both old and new shapes. Enforcement begins in Chrome 145 — update before that release to avoid production breakage. (developer.chrome.com)
• Risk level: High for IdPs and RPs that haven’t validated their .well-known and assertion parsing; medium for consumer sites using third‑party IdPs (confirm with providers).

Bottom line If your stack handles sign‑in with FedCM (either as an IdP or RP), treat this as a platform‑level API change: update ID assertion outputs, publish required metadata, modify client nonce/error handling, and test in Chrome 143 now. Use the 143–144 transition period to roll changes safely before enforcement in Chrome 145. (developer.chrome.com)

Source: (Chrome for Developers) (developer.chrome.com)

Source

• Source