Web技术

安全上下文：此功能仅在安全上下文（HTTPS）、某些或所有支持的浏览器中可用。

凭证管理API使网站能够创建、存储和检索凭证。凭证是使系统能够做出身份验证决定的项目：例如，决定是否将用户登录到帐户。我们可以将其视为用户向网站提供的一项证据，以证明他们真的是他们所声称的那个人。

概念和用法

中心接口是CredentialsContainer，它可以通过navigator.credentials属性访问，并提供三个主要功能：

• create（）：创建一个新凭据。
• store（）：在本地存储一个新凭据。
• get（）：检索一个凭据，然后可以使用该凭据登录用户。

API支持四种不同类型的凭证，它们都表示为凭证的子类：

网站包含几种不同类型的信息。其中一些是非敏感的，例如公共页面上显示的副本。其中一些是敏感的，例如客户用户名、密码和银行信息，或者内部算法和私人产品信息。

敏感信息需要得到保护，这是网络安全的重点。如果这些信息落入坏人之手，可能会被用来：

• 通过与竞争对手共享信息，使公司处于竞争劣势。
• 禁用或劫持他们的服务，再次导致他们的操作出现严重问题。
• 将客户的隐私置于危险之中，使他们容易受到分析、定位、数据丢失、身份盗窃甚至经济损失的影响。

现代浏览器已经有几个功能来保护用户在网络上的安全，但开发人员也需要谨慎地采用最佳实践和代码，以确保他们的网站是安全的。即使是代码中的简单错误也会导致漏洞，坏人可以利用这些漏洞窃取数据并控制他们没有授权的服务。

本文介绍了网络安全，包括有助于您了解网站易受攻击的方面以及如何保护网站的信息。

安全与隐私的关系

安全和隐私是不同的主题，但它们也密切相关。了解两者之间的区别以及它们之间的关系是值得的。

本文解释了什么是第三方cookie，描述了与它们相关的问题，并解释了如何解决这些问题。

什么是第三方cookie？

cookie与特定的域[domain ]和方案[scheme ]（通常为https）相关联，如果设置了“设置cookie域”属性，则也可能与子域相关联。

• 如果cookie域和方案与用户正在查看的当前页面（浏览器地址栏中显示的URL）匹配，则cookie被认为与页面来自同一网站，并被称为第一方cookie。
• 如果域和方案不同，则cookie不被视为来自同一网站，并被称为第三方cookie。

注意：第三方cookie有时被称为跨站点cookie。这可以说是一个更准确的名称，因为第三方cookie意味着第三方公司或组织的所有权。然而，无论您是否拥有所有相关网站，行为和潜在问题都是相同的。例如，一个网站可能会访问来自其拥有的不同域的资源，例如图像。

当用户第一次访问页面、跟随到同一网站上的另一页面的内部链接或请求驻留在同一网站的资源（例如，嵌入式图像、网页字体或JavaScript文件）时，可以设置第一方cookie。

Web开发人员可以使用多种技术将数据存储在用户的浏览器中（即，存储在用户用于查看网站的设备的本地磁盘上）。

浏览器允许网站存储的数据量以及在达到该限制时删除数据的机制因浏览器而异。

本文介绍了可用于存储数据的网络技术，浏览器限制网站存储过多数据的配额，以及它们在需要时删除数据的机制。

浏览器如何将数据从不同的网站中分离出来？

浏览器将来自网站的数据存储在不同的地方，也称为bucket，以降低用户在网络上被跟踪的风险。在大多数情况下，浏览器按每个来源【per origin】管理存储的数据。

因此，术语起源对于理解这篇文章非常重要。源由方案（如HTTPS）、主机名和端口定义。例如，https://example.com和https://example.com/app/index.html属于同一个源，因为它们具有相同的方案（https）、主机名（example.com）和默认端口。

安全上下文：此功能仅在安全上下文（HTTPS）、某些或所有支持的浏览器中可用。

Web身份验证API（WebAuthn）是凭证管理API的扩展，可通过公钥加密实现强身份验证，实现无密码身份验证和无SMS文本的安全多因素身份验证（MFA）。

注意：密钥是web身份验证的一个重要用例；有关实现的详细信息，请参阅为无密码登录创建密钥【 Create a passkey for passwordless logins】和通过表单自动填充使用密钥登录【 Sign in with a passkey through form autofill】。另请参阅Google Identity>Passwordless login with passkeys。

本文描述了依赖方（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、指纹识别和其他浏览器状态的限制都旨在降低创建或访问全局身份的能力。

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