联合凭证管理（Federated Credential Management）FedCM API

联合凭证管理（Federated Credential Management）API简称`FedCM`，后面咱们统一用这个简称，咱们可以这样叫它：`Fed C M`。

背景

Chrome即将在2024年禁用第三方Cookie。这势必会导致一些现有的一些业务无法进行。Chrome团队为了避免这种情况，发布了一系列的替代方案，这些替代方案被统称为Privacy Sandbox。不过Privacy Sandbox虽然是因为第三方Cookie的终结而诞生的，但是仅仅出一些零散的替代方案显然不是谷歌的风格，谷歌升华了Privacy Sandbox，把它打造成了一个保护用户在线隐私的集成解决方案。不得不说，大厂都比较喜欢玩儿概念，概念总是有一种升华的感觉，更容易推广。

简介

FedCM就是Privacy Sandbox计划的一部分。简单的说，第三方Cookie被禁用带来了一系列问题，FedCM就是针对其中一个细分场景问题的解决方案。

FedCM要解决的问题是这样的细分场景：第三方登录、单点登录。这些场景中时常会使用第三方Cookie、iframe、redirect重定位等技术，而这些技术经常会被用于追踪用户，导致用户隐私泄漏，因此浏览器对它们的限制越来越多。

其实禁用第三方Cookie对国内的第三方登录业务几乎没有影响，因为国内基本都是用App扫码的方式登录，像微信登录这种的，扫码登录成功后通过URL回传给业务网站一个code参数，然后业务网站通过后台服务器与微信服务器通信获取用户的登录信息，整个过程完全不需要第三方Cookie。国内对二维码技术可以说是充分使用，给用户带来了巨大的便利，这一点即使是国外也不能及。

下面咱们就来具体地介绍FedCM。

FedCM的适用场景

场景1

如果你的登录业务依赖第三方登录，以下条件同时满足时，则FedCM适用：

第三方服务不是你自己公司的服务，而是一个通用登录服务。
第三方登录服务通过第三方Cookie实现。

场景2

如果你是第三方登录服务方，以下条件同时满足时，则FedCM适用：

你所服务的业务不是你公司内部的业务，也不是少数合作伙伴的业务，而是一个有着大量合作网站的通用登录服务。
第三方登录服务通过第三方Cookie实现。

这些场景在国内几乎不存在，不过大家还是了解一下FedCM为好。

有些大公司内部会有多个业务系统，可能会使用单点登录的机制，可能会依赖第三方Cookie，对于这种情况Chrome有专门的应对方案：Related Website Sets相关网站集，这个我们会另开一片文章来讲。

浏览器兼容情况

目前只有最近几个版本的Chrome和Edge浏览器支持FedCM，不过其他大厂也在支持的路上。如果你想使用FedCM，那你一定要做好兼容判断，除非你可以控制用户浏览器的版本，否则FedCM方案和第三方Cookie方案都得有，

FedCM的大体流程

整个FedCM实际上就是用户、业务网站、浏览器、第三方登录服务之间的一个交互过程。我们下面就从各个方面来看一下整个流程，希望能帮助大家快速地对FedCM有一个大概的了解。

从用户角度看

用户进入业务网站

--> 网站弹出账号列表

--> 用户选择一个账号登录，用户登录成功，继续业务网站的操作。

从业务网站角度看

用户进入业务网站

--> 网站调用FedCM的API向第三方登录服务获取用户的信息，该API返回Promise

--> 成功获取到了用户信息后，用户选择登录

--> FedCM的API返回的Promise变成resolve状态，并且回传了token

--> 业务网站获取到token后，对其进行解析拿到用户的具体信息，做注册或者登录操作，然后业务网站给该用户发放一个用户标识Cookie，用户登录成功。

从浏览器角度看

--> 渲染业务网站

--> FedCM的API被调用，传入了第三方登录服务的配置文件URL。例如：https://accounts.idp.example/config.json

--> 浏览器解析出URL所对应的一级域名。例如：accounts.idp.example的一级域名就是idp.example。

--> 浏览器同时发出两个请求，一个是https://accounts.idp.example/config.json，还有一个是https://idp.example/.well-known/web-identity。

--> 浏览器对比.well-known/web-identity请求中返回的provider_urls参数和FedCM API调用时传入的配置文件URL，如果不同，API调用失败，Promise被reject，笔者测试时发现如果不同时，虽然浏览器已经在控制台报出了错误，但是返回的Promise过了很久才被reject。很显然浏览器的实现还不成熟。

--> 如果.well-known/web-identity和API传入的配置文件URL相匹配，则浏览器开始向配置文件中指定的accounts_endpoint发送请求，用于获取用户的账号信息，此时会带上第三方服务在浏览器端种的Cookie。

--> 账号信息获取成功后，开始向指定的client_metadata_endpoint发送请求，来获取隐私条款和服务条款链接。这一步不是必须。

--> 浏览器让用户选择一个账户，并要求用户确认是否要使用该账户登录（也有可能自动登录），用户一旦选择继续登录，则又会向配置文件中指定的id_assertion_endpoint发请求，并向其传入用户账号等信息，同时还会带上第三方服务在浏览器端种的Cookie。

--> 第三方服务确认之后，返回一个token参数。

--> 浏览器端FedCM的API返回的Promise成功resolve，获取到了第三方服务返回的token。

--> FedCM流程结束。

用文字来解释整个流程确实比较苍白。下面咱们通过一张流程图来解释整个流程。

完整流程图

了解完大体流程之后，我们再来看具体的代码，讲具体的规则，大家可以照着我下面的步骤在自己电脑上尝试搭建整个流程，只有自己尝试过之后才能更印象深刻。

必须使用HTTPS或localhost

如果要想使用FedCM的API，那业务网站和第三方登录服务的访问协议有如下要求：必须是HTTPS，如：https://xxx 或者是本地服务：http://localhost:xxx/xxx 或者是本地服务：http://127.0.0.1:xxx/xxx

否则API将无法访问，navigator.credentials会是undefined。

FedCM的API

对于开发人员来说，还是看代码最有感觉。下面咱们就来讲代码。

FedCM的API主要是指浏览器端的JavaScript API，API非常简单，举例如下：

javascript 复制代码

const credential = await navigator.credentials.get({
  identity: {
    context: 'signup',
    providers: [{
      configURL: 'https://accounts.idp.example/config.json',
      clientId: '********',
      nonce: '******',
      loginHint: '[email protected]'
    }]
  }
});
const { token } = credential;

上面这段代码就是我们上面流程图的开端。如果代码运行成功，浏览器会弹出如下界面：

该界面里的内容只是示例，实际内容根据实际的账户信息而定。

该界面是让用户选择一个账号进行登录或者注册。

当navigator.credentials.get()开始执行，则代表FedCM的流程开始，一旦该API返回的Promise被resolve或者被reject，则代表整个FedCM流程结束。 navigator.credentials.get()其实就是整个FedCM的核心，其他所有操作都围绕着它展开。

API虽然简单，但是这个API调用时，浏览器会执行一系列的操作，这个才是重点。

下面咱们就讲一下执行流程。

API的执行流程

遵循CSP

navigator.credentials.get()一旦执行就会向第三方登录服务发送请求，这里要注意的是，它依然遵循CSP（Content Security Policy）的设置。如果业务网站设置了CSP，那CSP的connect-src必须允许所有的FedCM相关的请求。

两个请求并行发出

navigator.credentials.get()一旦开始执行，浏览器会首先并行发送两个GET请求，在该例子中是：

well-known请求：https://idp.example/.well-known/web-identity
configURL请求：https://accounts.idp.example/config.json。

well-known请求

well-known请求是一个比较特殊的请求，它浏览器自发请求的，并不需要在代码中指定。它的请求路径是固定的：/.well-known/web-identity。它的域名是navigator.credentials.get()中configURL参数所指定的域名所对应的一级域名，例如： accounts.idp.example所对应的一级域名就是idp.example。这里所说的一级域名就是指顶级域名的下一级域名，我们注册域名时注册的都是一级域名。因此，如果configURL是https://accounts.idp.example/config.json，那well-known请求就是https://idp.example/.well-known/web-identity。

https://idp.example/.well-known/web-identity需要以这样的格式返回数据：

javascript 复制代码

{
  "provider_urls": ["https://accounts.idp.example/config.json"]
}

这一点比较好理解，这时和浏览器的约定格式。

configURL必须在well-known中列出

provider_urls中指定的内容必须和浏览器API中的configURL一致，如果不一致，上面的await语句会抛异常，同时控制台会给出一个错误提示Provider's FedCM config file not listed in its well-known file.，它的意思是说配置文件没有在well-known文件中列出。

那为什么需要第三方登录服务声明一个well-known呢？根据社区的说法是怕第三方服务对用户的行为进行追踪。虽然navigator.credentials.get()是由业务网站执行，但是一般业务网站会直接使用第三方登录服务封装好的SDK，如果第三方服务这样去封装它的API：

javascript 复制代码

const credential = await navigator.credentials.get({
  identity: {
    context: 'signup',
    providers: [{
      configURL: `https://accounts.idp.example/fedcm?rp=${encodeURIComponent(location.href)}`,
      clientId: '********',
	  ...
    }]
  }
});
const { token } = credential;

例子中可以看到configURL是https://accounts.idp.example/fedcm?rp=${encodeURIComponent(location.href)} 第三方登录服务把业务网站的域名放入configURL，这样就可以轻松最终用户在使用哪个网站。如果要求configURL必须和预先声明的well-known中provider_urls指定的内容一致，那configURL就无法被修改，因此也就无法形成追踪。

你可能会觉得有这种可能：第三方服务完全可以在well-known请求中根据HTTP的Origin来动态的返回provider_urls。事实上这一点无法做到，因为浏览器不会在HTTP头中放入Origin，具体请看下面的讲解。

以上两HTTP请求的特点

浏览器发送的这两个GET请求有如下特点：

HTTP头中不会带Origin和Referer字段。
不会带Cookie。
不会遵守redirect重定向规则。
会带有Sec-Fetch-Dest: webidentityHTTP头。
返回数据只接收application/json的Content-Type。

1、2主要是为了阻止第三方登录服务获知用户想在哪个网站登录，从而阻止了用户隐私泄漏。 Sec-Fetch-Dest: webidentity是为了防止CSRF跨站请求伪造，第三方登录服务必须确认有该HTTP头存在才是合法的请求。

下面是一个示例的HTTP请求头：

makefile 复制代码

GET /config.json HTTP/1.1
Host: accounts.idp.example
Accept: application/json
Sec-Fetch-Dest: webidentity

配置文件请求

configURL请求返回后浏览器获取到了第三方登录服务的配置信息，配置信息格式如下：

javascript 复制代码

{
      accounts_endpoint: '/accounts',
      client_metadata_endpoint: '/client_metadata',
      id_assertion_endpoint: '/assertion',
      branding: {
        background_color: 'green',
        color: '#FFEEAA',
        icons: [{
          url: 'https://idp.example/icon.ico',
          size: 25,
        }],
      }
}

属性	描述
`accounts_endpoint`（必填）	获取账号的请求路径
`client_metadata_endpoint`（可选）	获取元数据的请求路径
`id_assertion_endpoint`（必填）	获取验证账号的请求路径
`branding` （可选）	用于设置和用户交互的面板的样式
`branding.background_color`（可选）	"继续"按钮的背景色，和CSS使用方式一致
`branding.color` （可选）	"继续"按钮的文本颜色，和CSS使用方式一致
`branding.icons` （可选）	一个数组，每个成员有两个属性： 1. url（必须）：icon图片的URL，不支持SVG。 2. size（可选）：icon的尺寸，会按照正方形显示，因此只需要一个值。该值必须大于等于25｜

示例如下：

返回的数据只能被浏览器使用，业务网站并不能拿到这些数据。

浏览器拿到配置文件后，会依次串行的对几个endpoint进行请求。下面就按照请求的顺序分别讲解这几个endpoint。

accounts_endpoint请求

浏览器拿到配置文件后，首先就是获取账号信息。accounts_endpoint必须是URL的路径部分，而不能是一个完整的URL，这样可以保证它和配置文件在一个域名下。浏览器拿到配置文件后，就开始向accounts_endpoint发送请求，来获取曾经在该浏览器登录过第三方登录服务的用户。

请求的特点如下：

是GET请求。
携带Cookie。
没有client_id参数。
没有Origin RefererHTTP头。
Content-Type必须是application/json。
带有Sec-Fetch-Dest: webidentity，用于防治CSRF。 HTTP请求示例如下：

makefile 复制代码

GET /accounts.php HTTP/1.1
Host: accounts.idp.example
Accept: application/json
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

这里最关键的是，浏览器会带上Cookie信息，这个Cookie是第三方登录服务存储在浏览器上的Cookie。在业务网站的环境下，这个Cookie就是第三方Cookie，所以其实第三方Cookie也并不是完全禁止，只是在一般情况下被禁止，在FedCM流程中依然会使用第三方Cookie。

如果之前用户在当前浏览器登录过第三方登录服务的网站，那就会有标识用户的Cookie存入浏览器。当用户使用其他业务网站，同时使用FedCM时，第三方登录服务就可以凭借之前在浏览器端种入的Cookie得知客户端用户的身份，从而找出所有的相关账户信息。

这时第三方Cookie是必须的，没有它FedCM无法往下进行。

如果第三方登录服务没有发现可以表示用户身份的Cookie，则会认为该用户之前没有登录过第三方登录服务的网站，从而不知道有哪些相关账号可以返回给浏览器。这时可以返回HTTP 401（代表未授权）。

如果第三方登录服务发现了可以表示用户身份的Cookie，则找出所有相关的账户信息，返回给浏览器。

账号信息的返回数据格式如下例：

javascript 复制代码

{
 "accounts": [{
   "id": "1234",
   "given_name": "John",
   "name": "John Doe",
   "email": "[email protected]",
   "picture": "https://idp.example/profile/123",
   "approved_clients": ["123", "456", "789"],
   "login_hints": ["demo1", "[email protected]"],
  }, {
   "id": "5678",
   "given_name": "Johnny",
   "name": "Johnny",
   "email": "[email protected]",
   "picture": "https://idp.example/profile/456"
   "approved_clients": ["abc", "def", "ghi"],
   "login_hints": ["demo2", "[email protected]"],
  }]
}

从例子可以看到，返回的账户信息是账户的列表，每个属性的意义解释如下：

属性	描述
`id`（必填）	账号的id
`name`（必填）	账号名字
`email`（必填）	邮箱地址
`given_name`（可选）	英语文化中，一个人会有一个或多个给定名字
`picture`（可选）	头像URL
`approved_clients`（可选）	业务网站`clientId`的列表，`clientId`代表业务网站，因此它表示该账号在哪些业务网站注册登录过
`login_hints`（可选）	字符串数组，第三方登录服务有可能会返回多个账户信息，浏览器端通过指定`loginHint`来过滤出目标账户，过滤操作在浏览器中进行

返回的数据只能被浏览器使用，业务网站并不能拿到这些数据。

笔者个人感觉这个设定的通用性不太好，像email这种东西在国内使用很少，因此在国内很多网站这都不是强制要求的，这边更流行手机号。这让会让国内很难认可FedCM。

client_metadata_endpoint请求

获取完账户信息后，浏览器会开始获取metadata元数据。这是一个串行的过程，浏览器会等账户信息请求完成，才会继续下一个请求。

和accounts_endpoint一样，client_metadata_endpoint也只是个URL的路径，不可以是完整的URL，这样可以保证它和配置文件在一个域名下。

metadata元数据中包含业务网站的隐私政策和服务条款。业务网站需要预先将这两个内容的链接交给第三方登录服务。如果用户首次在某业务网站进行登录注册，浏览器就会发出client_metadata_endpoint的请求。

请求的特点如下：

是GET请求。
会带上client_id，注意请求中是client_id而不是clientId。
不带Cookie。
有Origin头。
返回数据的Content-Type必须是application/json。
有Sec-Fetch-Dest: webidentity头，用于防止CSRF跨站脚本攻击。

请求示例如下：

makefile 复制代码

GET /client_metadata.php?client_id=1234 HTTP/1.1
Host: accounts.idp.example
Origin: https://rp.example/
Accept: application/json
Sec-Fetch-Dest: webidentity

返回的数据格式示例如下：

javascript 复制代码

{
  "privacy_policy_url": "https://rp.example/privacy_policy.html",
  "terms_of_service_url": "https://rp.example/terms_of_service.html"
}

每个属性的解释如下：

属性	描述
`privacy_policy_url`（可选）	业务网站的隐私策略URL
`terms_of_service_url`（可选）	业务网站的服务条款URL

返回的数据只能被浏览器使用，业务网站并不能拿到这些数据。

隐私策略和服务条款的显示方式：

id_assertion_endpoint请求

浏览器获取到账户列表后，用户就可以选择一个账户来对业务网站进行注册或者登录了，用户确认选择某个账户后，浏览器还会向第三方登录服务发送一个POST请求，来对用户选择的账号进行确认，第三方登录服务确认后，会返回一个token，这就标志着整个FedCM流程的结束。这个请求的地址就是id_assertion_endpoint指定的地址。

和accounts_endpoint一样，client_metadata_endpoint也只是个URL的路径，不可以是完整的URL，这样可以保证它和配置文件在一个域名下。

id_assertion_endpoint的请求特点如下：

是POST请求。
请求的Content-Type是application/x-www-form-urlencoded。
会携带上Cookie。
会携带上OriginHTTP头。
带有Sec-Fetch-Dest: webidentity，用于防止CSRF跨站请求伪造。

请求示例如下：

makefile 复制代码

POST /assertion.php HTTP/1.1
Host: accounts.idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity

account_id=123&client_id=client1234&nonce=Ct60bD&disclosure_text_shown=true

POST请求发送的数据的解释如下：

属性	描述
`client_id`（必填）	业务网站的`clientId`，业务网站向第三方登录服务申请时，由第三方登录服务发放
`account_id`（必填）	用户的账号ID
`nonce`（可选）	随机值，由`navigator.credentials.get()`提供
`disclosure_text_shown`	该值由浏览器提供，有"true"和"false"两种可能，注意是字符串，而不是布尔值。 "true"代表向用户显示了隐私政策和服务条款，"false"表示没有显示。有两种情况会是"false"： 1. `accounts_endpoint`返回的账户信息列表中，某个账户的`approved_clients`中包含了当前业务网站的`clientId` （说明用户之前已经同意过登录该业务网站，不再需要显示隐私条款等信息） 2. 用户刚刚在浏览器端用选定账户登录过

第三方登录服务拿到这些数据后至少要做如下验证：

account_id必须和当前登录用户的一致。当前用户的登录情况可通过传回的身份标识Cookie获知。
OriginHTTP头必须和业务网站的域名一致，业务网站要使用第三方登录服务，肯定是需要预先向该服务进行注册，注册时肯定需要填入其域名信息。

验证通过后，需要按照如下格式返回token字符串：

javascript 复制代码

{
  "token": "***********"
}

HTTP的Content-Type必须是application/json。

该token具体是什么格式FedCM并没有指明。但它很有可能是一个类似于JWT形式的token，里面涵盖了用户的用户名等信息，业务网站拿到它后可以解析出里面的信息，从而完成注册或者登录。

流程结束

至此整个FedCM的流程结束，navigator.credentials.get()返回的Promise开始resolve或者reject。

最终resolve返回的是IdentityCredential的实例，IdentityCredential继承于Credential类，而Credential又是整个Credential Management API的一员。这是Web的一整套凭证管理体系。

这里再贴出整个API的示例代码：

javascript 复制代码

const credential = await navigator.credentials.get({
  identity: {
    context: 'signup',
    providers: [{
      configURL: 'https://accounts.idp.example/config.json',
      clientId: '********',
      nonce: '******',
      loginHint: '[email protected]'
    }]
  }
});
const { token } = credential;

API中几个参数的意义

从上面的例子中我们可以看到FedCMAPI有好几个参数，下面我们分别讲一下它们的含义。

API示例如下：

javascript 复制代码

const credential = await navigator.credentials.get({
  identity: {
    context: 'signup',
    providers: [{
      configURL: 'https://accounts.idp.example/config.json',
      clientId: '********',
      nonce: '******',
      loginHint: '[email protected]'
    }]
  },
  mediation: 'optional', // 默认值
});
const { token } = credential;

context属性

非必填 FedCM的API被调用成功后，会弹出如上的UI让用户确认，该UI是浏览器自带的，不需要开发人员开发，但是我们实际使用时会有多种场景，会有不同的话术，context就是为了控制UI的显示话术，代表着目前的上下文。有几个可选项：signin signup use continue，默认是signin signin，表示要通过第三方登录服务登录到业务网站 signup，表示要通过第三方登录服务注册到业务网站 use，表示要通过第三方登录服务使用业务网站 continue，表示要通过第三方登录服务继续操作业务网站经过笔者测试，Edge和Chrome的话术不太一样，而且话术还比较生硬，其实默认值signin已经基本满足我们绝大部分业务需求了。

providers

可以看到providers是一个数组，也就是说可以支持多个第三方登录服务。但是目前的Chrome最新版本119版还没有将此功能打开，目前默认支持的providers数组的长度是1。

支持多个第三方登录服务有比较难解决的问题：虽然FedCM的API是在业务网站执行，但是一般都是由第三方登录服务封装好SDK，业务网站直接使用SDK。这就带来了一个问题，当要集成多个第三方的SDK时，navigator.credentials.get由哪个SDK来调用就成了一个问题了，这时providers数组也就没有了用武之地。

因此我们只能拭目以待，看看Chrome团队、W3C、社区能想出什么好的方案。

clientId

必填该属性是第三方登录服务分配给业务网站的标识。当请求发生时，第三方服务可以通过clientId来得知具体是哪个业务网站的请求。并不是所有的请求都会带上clientId，只有meta data请求和assertion请求会带上clientId。

nonce

非必填一个随机值，浏览器通过对请求和响应中的nonce进行对比，可以防止重放攻击。

loginHint

非必填第三方登录服务可能会提供多个曾经在当前浏览器环境登录过的账号，loginHint可以起一个过滤的作用，第三方登录服务返回的账号列表中可以给每个账号都带有一个loginHint属性，客户端指定的loginHint和服务端会返回的进行对比，只有匹配的账户才会对用户显示。 loginHint并不会传给服务端，整个过滤过程在浏览器端完成。

只此FedCM的核心知识点我们就讲完了。

下面再进行一些完善。

mediation

当用户重复登录时，mediation用于控制是否需要用户进行确认。例如，我们初次注册或登录时，当用户选择完一个账号后（只有一个账号时不需要选择账号），会有这样的确认按钮，需要用户点击：

用户刚刚已经确认过了，用户再次刷新页面进来时，就没有必要再次让用户确认了，因此浏览器会直接帮用户自动登录。这是FedCM的默认行为。

但是有时我们可能希望每次都需要用户确认后才能登录，这时就可以用mediation来进行控制。 mediation有如下几个选项：optional required silent。分别解释如下： optional：默认值。如果用户在短时间内重复进入，且上次刚刚确认过了，那就不需要再确认了，直接自动注册或登录。 required：顾名思义，每次都需要用户点击按钮进行确认。 silent：总是静默，不需要用户点击按钮确认。如果能自动登录就自动登录，如果不能就自动失败，返回的Promise直接reject。

当有多个可选账户时，笔者发现无论是Chrome还是Edge，对于自动登录的控制都不是很稳定。所以对于这部分规则咱们也不用细究了，价值不大。

用preventSilentAccess()强制用户确认

自动登录功能虽然好，但是如果用户刚刚登出了业务网站，页面刷新后，如果这时自动登录功能还在生效状态，又自动帮助用户进行了登录，那就是一个非常差的用户体验了。

因此FedCM有一个策略，就是每10分钟内，自动登录的次数不会超过1次。除非用户主动按了确认按钮来主动登录，这时下次的会自动登录。

如果想强制阻止自动登录，可以调用navigator.credentials.preventSilentAccess()，这时会关闭下一次的自动登录，不过也仅仅是关闭一次。

Chrome中，用户也可以自己关闭自动登录功能：chrome://password-manager/settings。

第三方登录服务要做的事

第三方登录服务方的服务器需要对这几个HTTP请求作出响应：

一级域名下的/.well-known/web-identity的URL请求。
配置文件请求。
账号列表请求。
metadata元数据请求。
账号确认请求。

另外不管是业务网站还是第三方登录服务，所有的Http请求协议都必须是HTTPS的或者是本地调试时使用localhost或者127.0.0.1，否则FedCM的API将无法访问。

这几项要做的事情的具体内容已经在上面讲过了，这里列出只是为了方便大家查询。

跨域的iframe中也可以使用FedCM

在一个和主网站域名不一样的跨域iframe中，也可以使用FedCM。但是需要iframe标签中加入特殊属性。其实意思就是需要主网站的允许。

iframe示例代码如下：

html 复制代码

<iframe src="https://fedcm-cross-origin-iframe.glitch.me" allow="identity-credentials-get"></iframe>

其中allow="identity-credentials-get"就是所说的特殊属性。

另外，主网站如果想限制FedCM的请求域名，也可以在页面的HTTP响应头中加入Permissions-Policy头： Permissions-Policy: identity-credentials-get=(self "https://fedcm-cross-origin-iframe.glitch.me") Permissions-Policy的值是所有允许域名的列表，以空格分隔，self代表网站自身的域名。

结束语

到此我们的讲解就结束了。

联合凭证管理（Federated Credential Management），简称FedCM，是一个非常新的浏览器新特性，是Chrome的Privacy Sandbox的方案之一。

Chrome团队在不遗余力的推动该特性的标准化，不过按照W3C的速度，这个特性估计至少还需要5年才能真正的被纳入标准，很有可能不过在这之前所有主流浏览器都已经很好地支持了该特性。

在国内，FedCM和其他第三方登录比，并没有太多优势，在国内的使用估计不会很多。