本文描述了依赖方（RP）可以使用联合凭据管理（FedCM）API通过身份提供程序（IdP）执行联合登录的过程。

调用get（）方法

RP可以使用标识选项调用navigator.credential.get（），以请求用户使用他们已经在浏览器上登录的现有IdP帐户登录RP。IdP通过其客户端ID来识别RP，该客户端ID是由IdP在特定于IdP的单独进程中发布给RP的。IdP使用登录时提供给浏览器的凭据（cookie）来识别特定用户。

如果IdP成功验证了用户身份，该方法将返回一个承诺，该承诺将通过IdentityCredential对象实现。此对象包含一个令牌，该令牌包含已使用IdP的数字证书签名的用户身份信息。

RP将令牌发送到其服务器以验证证书，一旦成功，就可以使用令牌中的（现在受信任的）身份信息将他们登录到其服务（启动新会话），如果他们是新用户，则可以将他们注册到其服务，等等。

如果用户从未登录过IdP或已注销，则get（）方法会拒绝并返回错误，RP可以将用户引导到IdP登录页面以登录或创建帐户。

本文详细介绍了身份提供程序（IdP）与Federated Credential Management（FedCM）API集成所需的所有步骤。

实验：这是一项实验技术
在生产中使用之前，请仔细检查浏览器兼容性表。

联合凭据管理API（或FedCM API）为身份提供者（IdP）提供了一种标准机制，使身份联合服务以保密的方式在网络上可用，而不需要第三方cookie和重定向。这包括一个JavaScript API，它允许在登录或注册网站等活动中使用联合身份验证。

FedCM概念

身份联合是指将用户身份验证从需要用户注册或登录的网站（如电子商务或社交网站（也称为依赖方或RP）委托给可信的第三方身份提供商（IdP），如谷歌、脸书/Meta、GitHub等。

依赖方（RP）可以与IdP集成，允许用户使用他们在IdP注册的帐户登录。与每个网站使用单独的用户名和密码管理自己的登录需求相比，通过一小组专用IdP进行的身份联合在安全性、消费者信心和用户体验方面改进了网络身份验证。

问题是，传统的身份联合依赖于<iframe>、重定向和第三方cookie，它们也用于第三方跟踪。浏览器正在限制这些功能的使用，以保护用户隐私，但副作用是，这使得有效的非跟踪使用更难实现，其中包括身份联合。

Web存储API提供了一些机制，浏览器可以通过这些机制以比使用cookie更直观的方式存储密钥/值对。

概念和用法

Web存储中的两种机制如下：

• sessionStorage为每个给定的源维护一个单独的存储区域，该存储区域在页面会话期间可用（只要浏览器选项卡打开，包括页面重新加载和恢复）。
• localStorage也做同样的事情，但即使浏览器关闭并重新打开，它也会持续存在。

这些机制可通过Window.sessionStorage和Window.localStorage属性获得。调用其中一个将返回存储对象的实例，通过该实例可以设置、检索和删除数据项。会话存储和本地存储分别使用不同的存储对象作为每个源——它们分别起作用并受控制。

要了解使用API的可用存储量，以及超过存储限制时会发生什么，请参阅存储配额和驱逐(Storage quotas and eviction criteria.)标准。

共享Web标识

网络的身份模型包含了两种交互浏览器功能的隐含结果：

• 每个域的状态，尤其是cookie，它使eTLD+1能够保持访问者身份的一致性。由于3p cookie、iframe中的存储等原因，此身份扩展到顶级网站。
• 在浏览器中，在网页上共同出现的各方之间传递信息（通过DOM或JS中的共享状态、HTTP重定向或postMessage等机制）。

这种组合导致了广泛共享的跨站点身份，从而实现了对个人浏览活动进行全网跟踪的能力。全局静态标识符（如设备指纹识别，或由浏览者提供或秘密获取的PII）也提供了一条通往全局身份的独立路径。对cookie、指纹识别和其他浏览器状态的限制都旨在降低创建或访问全局身份的能力。

一方面，全球身份产生了将一个人的大部分浏览历史记录编织在一起的能力，这是当今网络的核心隐私问题。浏览器可以通过对暴露给开发人员的底层功能施加限制来对这个问题采取行动。另一方面，全球身份在当今的网络广告生态系统中也发挥着重要作用。如果浏览器没有满足生态系统的合法需求，那么对这些技术能力施加限制的浏览器可能会直接影响出版商的经济生存能力（更多细节！）并鼓励变通办法。

饼干最好是新鲜的，那么有什么最新的食谱可以确保你仍然可以在没有任何变质饼干的情况下享受诡异的季节呢？

我们正在逐步淘汰网络平台上的第三方cookie。这是解决跨站点跟踪问题的一个重要里程碑，但这是相当漫长的旅程的一部分。让我们来看看我们已经走了多远，未来会有什么美食…

从表面上看，cookie提供了一个在浏览器和服务器之间发送的简单键值存储。这可以在网站上提供有用的功能，例如保存首选项：theme=bats或存储已登录用户的会话ID。

介绍

Passkeys是一种更安全、更容易替代密码的方法。使用密钥，用户可以使用生物识别传感器（如指纹或面部识别）、PIN或模式登录应用程序和网站，从而无需记住和管理密码。

开发人员和用户都讨厌密码：它们给用户带来了糟糕的用户体验，增加了转换摩擦，并给用户和开发人员带来了安全责任。安卓和Chrome中的谷歌密码管理器通过自动填充减少了摩擦；对于寻求在转换和安全性方面进一步改进的开发人员来说，密钥和身份联合是该行业的现代方法。

密钥可以在一个步骤中满足多因素身份验证要求，取代密码和OTP（例如6位短信代码），以提供强大的保护，防止网络钓鱼攻击，并避免短信或基于应用程序的一次性密码带来的用户体验痛苦。由于密钥是标准化的，因此单个实现可以实现跨所有用户设备、跨不同浏览器和操作系统的无密码体验。

密钥更容易：

浏览器的同源策略阻止从不同的源读取资源。这种机制阻止恶意网站读取其他网站的数据，但也阻止合法使用。

现代web应用程序通常希望从不同的来源获取资源，例如，从不同的域检索JSON数据，或将另一个网站的图像加载到＜canvas＞元素中。这些可以是公共资源，任何人都可以阅读，但同源政策阻止了它们的使用。开发人员历来使用诸如JSONP之类的变通方法。

跨来源资源共享（CORS）以标准化的方式解决了这个问题。启用CORS可以让服务器告诉浏览器它可以使用一个额外的原点。

你为什么要关心隔离你的网络资源？

许多web应用程序容易受到跨来源攻击，如跨站点请求伪造（CSRF）、跨站点脚本包含（XSSI）、定时攻击、跨来源信息泄露或推测执行侧通道（Spectre）攻击。

Fetch Metadata请求头允许您部署一种强大的深度防御机制——资源隔离策略——以保护您的应用程序免受这些常见的跨源攻击。

由给定的web应用程序公开的资源通常只由应用程序本身加载，而不由其他网站加载。在这种情况下，部署基于Fetch Metadata请求头的资源隔离策略几乎不需要付出什么努力，同时可以保护应用程序免受跨站点攻击。

浏览器兼容性

所有现代浏览器引擎都支持获取元数据请求标头。

浏览器支持

大多数时候，http://localhost出于开发目的，其行为类似HTTPS。然而，也有一些特殊情况，例如自定义主机名或跨浏览器使用安全cookie，在这些情况下，您需要明确设置您的开发网站，使其表现得像HTTPS，以准确地表示您的网站在生产中的工作方式。（如果您的生产网站不使用HTTPS，请优先切换到HTTPS）。

本页介绍如何使用HTTPS在本地运行您的网站。

注意：在本文中，关于localhost的语句也适用于127.0.0.1和[：：1]，因为它们都描述了本地计算机地址（也称为环回地址）。为了简单起见，这些说明没有指定端口号。所以当你看到http://localhost，读作http://localhost:｛PORT｝或http://127.0.0.1:｛端口｝。

有关简要说明，请参阅mkcert快速参考**