Firebase App Check 和 reCAPTCHA v3 企业集成：计费和令牌可重用性

Question

我正在尝试使用 Firebase App Check 并以 reCAPTCHA v3 Enterprise 作为证明提供商来保护 Web 应用程序的自托管后端，但我对此设置的计费结构有一些疑问。

仅使用 reCAPTCHA v3 时，标准流程是使用 以编程方式在客户端调用质询grecaptcha.execute，检索令牌，然后将其发送到后端。随后，后端通过向 reCAPTCHA 服务器发出 API 请求来验证令牌。我对 reCAPTCHA Enterprise 定价页面的理解是，每次在后端验证令牌时我都会付费。

相比之下，Firebase App Check 的流程似乎略有不同。在这里，客户端通过 Firebase App Check 与 reCAPTCHA v3 交互，并接收令牌形式的“证明”。然后，客户端将此令牌发送到我的后端，我的后端通过向 Firebase 服务器发出请求来验证令牌的有效性。此外，Firebase App Check 令牌具有可配置的过期时间，并且可以重复使用，并且可以选择启用重播保护。

鉴于此，我不清楚 Firebase App Check 与 reCAPTCHA v3 集成时的计费方式。具体来说，我想知道：

1. 每次 Firebase App Check 颁发令牌时，还是仅当我在后端验证 Firebase App Check 颁发的令牌的有效性时，我都需要付费吗？
2. 与不重复使用令牌的传统 reCAPTCHA v3 方法相比，在 Firebase App Check 中重复使用令牌的能力是否可能会降低成本？

任何对这些问题的见解将不胜感激。

Answer 1

这里是 Firebaser，感谢您提出这个问题。

\n

为了回答你的两个问题，

\n

\n
1. 在后端验证App Check 令牌时，您无需付费。App Check 不会向您收费\xe2\x80\x94reCAPTCHA Enterprise 会收费。仅当 App Check 代表assessment.create()您调用时，他们才会向您计费，这种情况发生在 App Check 令牌的 TTL 已过大约 50% 时（如果您使用的 App Check 没有重播保护）。如果您使用带有重播保护的 App Check，则每次想要访问受保护的后端时都需要获取新的 App Check 令牌，这意味着assessment.create()每次都会调用，从而可能会增加创建的评估数量没有重播保护。因此，我们建议您仅在访问量较低的最安全敏感端点上使用重播保护。
\n
2. 是的，这种权衡是一个经过深思熟虑的功能。使用 App Check 的传统安全模型（即没有重播保护），我们会放弃一定程度的安全性，以换取在您可以配置的 TTL 范围内重复使用相同的 App Check 令牌。每次刷新仅assessment.create()调用一次，但请记住，App Check SDK 设计为在 TTL 已过大约 50% 时立即刷新令牌（有效刷新速度约为您配置的 TTL 速率的两倍）。您可以在 Firebase 控制台中调整此 TTL。
\n

\n

如果您对更详细的回复感兴趣，包括与新的重播保护功能的交互，请参阅下文。

\n

我注意到您的帖子提到了 reCAPTCHA v3 和 reCAPTCHA Enterprise，所以让我们首先注意它们之间的区别：

\n

\n
• reCAPTCHA v3 是免费的，并且每月可进行的评估数量有 1,000,000 次限制，要超过该限制，您必须迁移到 reCAPTCHA Enterprise 或申请豁免（须经批准）。它也没有支持或 SLA。
\n
• reCAPTCHA Enterprise 每月最多可免费调用 1​​,000,000 次，超出此数量则按成本付费。您是正确的，您的服务器调用的确切次数assessments.create决定了您的计费金额。它还包括基本支持和 99.9% 以上的正常运行时间 SLA。
\n

\n

对于我回复的其余部分，我假设您在帖子中指的是reCAPTCHA Enterprise（而不是reCAPTCHA v3）。

\n

让我们以 reCAPTCHA Enterprise 作为您的证明提供商来讨论 App Check。基本的客户端流程（没有重放保护）如下：

\n

\n
• 您的应用程序使用 App Check SDK在后台管理App Check 令牌。
\n
• 在 App Check 令牌过期之前，将使用以下令牌交换过程自动刷新令牌。（注意：App Check SDK 设计为在 TTL 已过约 50% 时刷新 App Check 令牌。在估计应用程序创建评估的次数时请记住这一点。）\n
  \n
  1. 致电grecaptcha.enterprise.execute()获取 reCAPTCHA Enterprise 令牌。
  \n
  2. 此 reCAPTCHA Enterprise 令牌将发送到 App Check 服务器。
  \n
  3. App Check 服务器assessment.create()代表您调用并读取评估，以确保 reCAPTCHA Enterprise 令牌有效。
  \n
  4. 如果有效，则会创建新的 App Check 令牌并将其返回给 SDK。
  \n
  \n
\n
• 每当您的应用程序需要向受 App Check 保护的后端端点发送请求时，您可以从 App Check SDK 检索当前的 App Check 令牌并将其与请求一起发送（通常作为 header X-Firebase-AppCheck）。如果您的应用程序使用官方 Firebase SDK 与受 App Check 保护的 Firebase 后端进行通信，则会自动为您完成此步骤。
\n

\n

这意味着 App Check（没有重播保护）本质上采用基于会话的模型，其中有效的 App Check 令牌是经过验证的应用程序会话的证明，并且只要未过期，它就有效。

\n

接下来，我们来谈谈基本的服务器端流程。我们建议您使用 Firebase Admin SDK执行以下步骤。

\n

\n
• 您的服务器接收来自应用程序的请求以及应用程序检查令牌。
\n
• 您的服务器使用 Admin SDK 验证 App Check 令牌。此步骤不需要将令牌发送到 App Check 后端（但它偶尔会从 App Check 服务器检索公钥，这是由 Admin SDK 自动处理的）。此特定的 App Check 令牌验证对您来说是免费的。
\n

\n

与直接与 reCAPTCHA Enterprise 集成相比，通过使用 App Check 基于会话的模型，您可以在多个因素之间进行权衡。我们在这里列出了您应该考虑的所有维度：

\n

\n
• 安全。请注意，与 reCAPTCHA Enterprise 的直接集成将具有内置的重播保护。也就是说，当为同一个 reCAPTCHA Enterprise 令牌创建两个单独的评估时，第二个评估将显示为无效。
\n
• 配额及计费。通过放弃 reCAPTCHA Enterprise 令牌的固有重播保护，您所获得的好处是创建的评估数量可能会减少，具体取决于您的流量模式。无论用户在 App Check 令牌达到刷新点之前需要访问受保护的后端多少次，该用户都只需要 1 次评估。
\n
• 表现。由于证明提供商握手不是免费运行的，因此它们可能会影响性能，尤其是在移动设备上。通过在后台刷新中使用 App Check 令牌，可以消除执行受保护操作之前的设备上延迟。
\n
• 联合提供商。由于 App Check 作为联合抽象层位于证明提供程序和您的服务器之间，因此您的服务器不再需要担心验证来自不同证明提供程序的令牌。它只需要了解一种令牌：App Check 令牌。这意味着您可以对服务器进行编程，以使用相同的代码为所有平台（例如，Web、Android 设备和Apple 设备）提供服务。App Check 服务器和 SDK 将处理令牌交换过程。如果现成的证明提供程序均不适用于您的目标平台，您甚至可以设置自己的自定义提供程序。
\n

\n

还可以通过增加或减少 App Check 令牌的 TTL来调整其中一些因素的权衡。

\n

到目前为止，我们已经讨论了传统的基于会话的模型，但正如您正确指出的那样，我们最近推出了新的重播保护功能。这项新功能使用一种完全不同的模型，该模型与与 reCAPTCHA Enterprise 的直接集成非常相似：对重播保护端点的每次调用都必须调用新的证明。根据定义，在上面的权衡列表中，我们选择在牺牲性能和计费的同时尽可能保证安全，但请注意，至关重要的是联合优势仍然存在。另一个关键区别是，与传统的基于会话的模型不同，Admin SDK 需要联系 Firebase App Check 后端来验证令牌之前是否未被使用过。然而，即便如此，这种验证仍然不需要您支付任何费用。

\n

此功能现已在 Cloud Functions for Firebase 以及您自己的后端上提供。我们建议开发人员使用此功能仅保护访问量较低的对安全最敏感的端点，因为它可能会比 App Check 的传统模型创建更多的评估（因为每个调用都需要一个新的评估，就像与 reCAPTCHA Enterprise 直接集成）。

\n

[编辑以修复一些遗漏。]

\n