Firebase verifyIdToken() 是否需要为缓存的每个新令牌调用 Firebase API?

Does Firebase verifyIdToken() needs a call to Firebase API for each new token when is cached?

我在一个项目中使用 Firebase,我使用 Firebase 令牌 ID 作为不记名令牌来验证用户。

项目工作正常,但我想知道在缓存时如何工作verifyIdToken()

现在项目是这样运行的:

  1. 客户端登录客户端APP并获取一个Firebase tokenId
  2. 客户端调用服务器使用tokenId作为要授权的Bearer token。
  3. 服务器使用 verifyIdToken() 验证用户。

问题与 verifyIdToken() 方法有关,是否需要在每个新令牌上调用 Firebase API。

我读过 问题,其中说:

VerifyIdToken() is also optimized for performance. It caches the Firebase token public cert (valid for 6 hours) which is used to validate the token signature on local machine. No RPC is involved except for downloading the public cert.

此外, 回答说:

When you call verifyIdToken, the Admin SDK decodes the token with the public key and verifies that the signature is valid. It downloads this key from Google's servers, but it's cached for 24 hours

以及评论:

verifyIdToken() fetches public keys from Google servers. But these get cached up to 24 hours, and so the RPC call overhead gets amortized.

但是,下载并缓存了什么证书?来自用户还是项目?

那么,服务器是否需要在每次从客户端获取新 tokenId 时调用 Firebase API,或者服务器是否可以在没有互联网连接的情况下使用缓存证书进行解码?

主要目标是减少对 Firebase 的调用次数API,所以我想知道如果每 24 小时下载一次 perm 缓存,服务器是否可以在没有互联网的情况下解码项目的每个有效令牌。

提前致谢。

But, what cert is downloaded and cached? From user or project?

ID 令牌是用私钥签名的。 SDK需要获取对应的public密钥证书来验证签名。这来自https://www.googleapis.com/robot/v1/metadata/x509/securetoken@system.gserviceaccount.com

So, do server needs a call to Firebase API on each new tokenId getting from the client or can the server decode without internet connection using cached cert?

服务器在第一次验证令牌时需要能够获取 public 密钥证书。然后,只要缓存的证书保持有效(最多 24 小时),它就可以在没有连接的情况下运行。但这不是您可以控制的,因此您不应该依赖它。

The main goal is to decrease number of calls to Firebase API, so I want to know if with perm cached downloaded every 24h, server can decode every valid token for the project without internet.

这取决于您的服务器是如何实现和部署的。 public 键缓存绑定到 SDK 创建的 Auth 对象实例。如果您的服务器是持久的,Auth 实例将保留在内存中,缓存也是如此。在这种情况下,您可以预期服务器每 24 小时进行大约 1 个 rpc(相同的缓存证书用于验证所有令牌)。

但是如果您的服务器是临时的(例如 Cloud Functions),那么 Auth 实例将被多次创建和清理。在这样的部署中,缓存不会产生很大的不同,服务器最终会为服务器的每次调用生成一个 rpc。