让我的 Firebase 应用程序专门触发微服务

Question

我有一个 Google VM 运行我的 dockerized 应用程序和我的 Firebase 前端应用程序。

我希望我的 Firebase 应用程序触发我的微服务。问题是，我想要有安全意识，我希望 Firebase 应用程序成为唯一可以触发微服务的参与者。

完成此类任务的最佳选择是什么？我发现的唯一东西是 json 网络令牌 (jwts)。这足以胜任这份工作吗？还有更好的吗？

如果需要jwts，那么代码应该有什么逻辑？如果服务器创建一个密钥并将其发送到微服务，那么微服务应该解码它并且只有当它匹配一个值时它才应该继续工作？

Answer 1

firebaser 在这里

新的 Firebase App Check 功能就是为这类事情而设计的，但尚未决定如何从您自己的服务器端代码访问此类应用程序令牌。

因此，App Check 目前允许特定的 Firebase 服务仅允许来自在项目中注册的应用的流量。您正在寻找另一面：只允许从这些应用程序到您的服务的流量，目前尚不支持。

另见https://groups.google.com/g/firebase-talk/c/rU0fEozdMyc/m/AYUa6PpLCAAJ

Answer 2

这里是 Firebaser。

我实际上并不完全确定您的架构，但如果您希望减少对在 Android、iOS 或 Web 上为您的 Firebase 应用程序提供服务的您自己的服务器的滥用，那么是的，我们正致力于在 App Check.

中支持此用例

但是，App Check 不是用于保护 server-to-server 通信（两个服务器都在您的控制之下）。在 Google 云上，这通常是使用服务帐户和 IAM 控件完成的。

除此之外，假设您想要第一件事而不是第二件事，并且假设您不想等待官方支持准备就绪，那么实际上有一种方法可以让您现在就做，但你必须自己做很多工作。此外，由于 App Check 目前处于 Beta 阶段，它可以以向后不兼容的方式进行更改，并且不受任何 SLA 或弃用政策的约束。

要获取 App Check 令牌，您可以对这些端点进行 POST。这些实际上是 SDK 在幕后使用的相同端点，因此您可以研究它们的来源以查看如何进行这些调用的示例。您还应该按照他们的示例，根据返回的 App Check 令牌的到期时间，定期 re-attest 应用程序和 re-obtain App Check 令牌。

[编辑：确保先在 App Check 中注册您的应用。在这里查看我们的 documentation。]

对于 DeviceCheck，使用 https://firebaseappcheck.googleapis.com/v1beta/projects/<project_number>/apps/<app_id>:exchangeDeviceCheckToken?key=<api_key>
- body 应该是一个 JSON object 和一个字符串字段 device_token。这是 Apple 的 client-side DeviceCheck API 返回的 device_token。这是 Base64 编码的 Data (Swift) 或 NSData (ObjC) object.
对于 reCAPTCHA v3，使用 https://firebaseappcheck.googleapis.com/v1beta/projects/<project_number>/apps/<app_id>:exchangeRecaptchaToken?key=<api_key>
- body 应该是一个 JSON object，只有一个字符串字段 recaptcha_token。这是 reCAPTCHA v3 JavaScript API.
对于 SafetyNet，使用 https://firebaseappcheck.googleapis.com/v1beta/projects/<project_number>/apps/<app_id>:exchangeSafetyNetToken?key=<api_key>
- body 应该是一个 JSON object，只有一个字符串字段 safety_net_token。这是发给您的应用程序的 SafetyNet attestation response。
对于自定义提供商，请按照我们的 public documentation 中的说明进行操作。但是，您不会在您的应用程序中使用 App Check SDK。相反，您需要直接编写代码来联系您的令牌服务器。

如果相应的令牌无效，这些端点将拒绝带有 403 Forbidden 的请求。您的客户端应该只在出现此类故障时重试有限次数，因为情况可能不会改变，如果您重试，您还应该使用相应的证明提供者重新运行整个证明流程。

一旦您的应用程序通过上述方式收到 App Check 令牌，您应该将其附加到对您要保护的 API（在您的服务器上）发出的每个请求中。例如，您可以通过 header 发送 App Check 令牌。一旦您的服务器收到这样的请求，请使用 Admin SDK Verify Token API 来验证此令牌。例如，

const admin = require("firebase-admin");

admin.initializeApp();

async function verifyToken(token) {
  admin.appCheck().verifyToken(token)
    .then((token) => {
      console.log(token.token)
    })
    .catch((e) => console.log(e))
}

这个验证令牌 API 实际上是我们的 Callable Functions SDK 在后台使用的。如果令牌无效，您的服务器应拒绝该请求。

请注意，此验证令牌 API 可以对我们的 public 密钥端点进行 GET 调用——但随后会被缓存一段时间，因此如果您带宽有限，周期有限 CPU，或者在令牌验证时没有缓存：

https://firebaseappcheck.googleapis.com/v1beta/jwks
- 此 returns 由 Section 5 of RFC 7517 指定的 JWK 集包含可用于验证我们的 App Check 令牌的 public 密钥。

同样，我们正在努力让您可以直接从 App Check SDK 检索 App Check 令牌，这样您就不必自己管理定期刷新或 POST 请求.请在下个月关注此功能。

让我的 Firebase 应用程序专门触发微服务

Let my Firebase application trigger microservice exclusively

authentication

jwt

firebase

microservices