fedcm无法在普通html页面直接调用，因其严格依赖https环境、permissions-policy显式启用、idp已注册且用户已登录等浏览器上下文约束。
为什么 FedCM 无法在普通 HTML 页面直接调用
FedCM（Federated Credential Management API）不是纯前端可自由调用的 JS 接口，它依赖浏览器的严格上下文约束：navigator.credentials.get() 中的 federated 选项只有在满足「第三方上下文 + 第一方 Cookie 已被隔离 + IdP 注册完成」时才可用。普通 HTML 页面（如 file:// 或未声明 Permissions-Policy 的 HTTP 页面）会直接抛出 NotAllowedError: Federated credential is not allowed in this context。
关键限制点：
- FedCM 只能在 HTTPS 环境下运行（
http://localhost是唯一例外） - 调用页面必须通过
Permissions-Policy: interest-cohort=(), gpc=(), browsing-topics=(), federated-credentials-get=()显式启用（否则 Chrome 128+ 默认禁用） - IdP（如 Google、Microsoft）必须已在
.well-known/web-identity发布符合规范的配置，并完成浏览器级注册（非开发者手动注册） - 用户必须已登录该 IdP 且未退出（FedCM 不触发登录弹窗，只读取已有会话）
如何正确触发 navigator.credentials.get({ federated: { providers } })
这不是一个“加个 script 就能跑”的功能，而是需要服务端配合的流程。典型可行路径是：前端发起请求 → 后端判断是否需联合登录 → 返回预签名的 FedCM 请求参数 → 前端调用 navigator.credentials.get。
实操要点：
- 确保页面响应头含
Permissions-Policy: federated-credentials-get=(self)（若仅允许同站调用）或federated-credentials-get=(self "https://idp.example")（指定 IdP） -
providers数组中每个元素必须是 IdP 的标准 URL（如"https://accounts.google.com"），不能是自定义域名或路径 - 必须在用户手势（如
click事件）中调用，不能在页面加载时自动触发，否则会被浏览器静默拒绝 - Chrome 目前仅支持 Google 和 Microsoft 作为 IdP；Firefox 和 Safari 尚未实现 FedCM
最小可运行示例（仅限 localhost）：
button.addEventListener('click', async () => {
try {
const cred = await navigator.credentials.get({
federated: {
providers: ['https://accounts.google.com']
}
});
console.log(cred.id, cred.provider); // 如 '123456789' 和 'https://accounts.google.com'
} catch (err) {
console.error(err.name, err.message); // 常见：'NotAllowedError' 或 'SecurityError'
}
});
FedCM 返回的 cred 对象里有什么，怎么用
它不返回 access token 或 ID token，只返回一个轻量级断言凭证（FederatedCredential 实例），核心字段是 id（用户在 IdP 的唯一标识）和 provider（IdP 源）。你**必须**将这两个值连同其他上下文（如 nonce、timestamp）一起发给后端，由后端向 IdP 的 Token Endpoint 发起后台请求换取正式 token。
注意点：
-
cred.id是 opaque string，不可解析、不可猜测，不同 IdP 格式不同（Google 是数字 ID，Microsoft 是 UUID） - 没有
cred.token或cred.rawId—— 这是故意设计，避免前端接触敏感凭据 - 后端验证时需检查
provider是否在白名单内，并使用 IdP 提供的 JWKS 验证签名（不能跳过） - 如果 IdP 会话已过期，
navigator.credentials.get会静默返回null，而非报错 —— 必须做空值判断
替代方案比 FedCM 更现实？
目前（2024 年中），FedCM 在生产环境落地难度远高于预期。大多数团队实际采用的是「混合模式」：用 FedCM 尝试无 Cookie 登录，失败后降级到传统 OAuth 2.0 授权码流（带 prompt=none 实现静默重定向）。
真正绕过第三方 Cookie 的可行路径其实是：
- 第一方上下文中用 Storage Access API 申请临时访问（
document.requestStorageAccess()），再读取自有 Cookie - 结合 CHIPS（
SameSite=None; Partitioned）维护跨站子域会话 - 用 WebID / DID 等去中心化身份方案（尚无主流浏览器原生支持）
FedCM 的价值不在“替代 OAuth”，而在为浏览器提供统一的、用户可控的身份选择界面 —— 但这个界面目前只对极少数已注册 IdP 开放，且高度依赖浏览器策略演进。别把它当登录 SDK 用，它更像一个受控的“身份门禁按钮”。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
