实现自定义 App Check 提供程序
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
App Check 内置了对多个提供方的支持:Apple 平台上的 DeviceCheck 和 App Attest、Android 上的 Play Integrity 以及 Web 应用中的 reCAPTCHA Enterprise(请参阅概览)。这些都是易于理解的提供程序,应该能满足大多数开发者的需求。不过,您也可以实现自己的自定义 App Check 提供程序。在以下情况下,需要使用自定义提供程序:
概览
若要实现自定义 App Check 提供方,您需要一个能够运行 Node.js Firebase Admin SDK 的安全后端环境。此环境可以是 Cloud Functions、Cloud Run 之类的容器平台,也可以是您自己的服务器。
在此环境中,您将提供一项网络可访问的服务,用于从应用客户端接收真实性证明,并在该证明通过真实性评估时返回一个 App Check 令牌。您用作真实性证明的具体指标将取决于您使用的第三方提供程序或您自己定义的指标(如果您要实现自定义逻辑)。
通常,您可以将此服务作为 REST 或 gRPC 端点公开,但具体细节由您决定。
创建令牌获取端点
安装并初始化 Admin SDK。
创建一个可以从客户端接收真实性数据的网络可访问端点。例如,使用 Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
// ...
});
向端点添加评估真实性数据的逻辑。这是自定义 App Check 提供方的核心逻辑,您必须自行编写。
如果您确定客户端是真实的,请使用 Admin SDK 创建一个 App Check 令牌并将其和相应的过期时间返回给客户端:
const admin = require('firebase-admin');
admin.initializeApp();
// ...
admin.appCheck().createToken(appId)
.then(function (appCheckToken) {
// Token expires in an hour.
const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;
// Return appCheckToken and expiresAt to the client.
})
.catch(function (err) {
console.error('Unable to create App Check token.');
console.error(err);
});
如果您无法验证客户端的真实性,请返回错误(例如,返回 HTTP 403 错误)。
可选:通过将 AppCheckTokenOptions
对象传递给 createToken()
,为自定义提供方颁发的 App Check 令牌设置存留时间 (TTL)。您可以将 TTL 设置为 30 分钟到 7 天之间的任何值。设置此值时,请注意权衡以下几个方面:
- 安全性:较短的 TTL 可以提供更强的安全性,因为它可以缩短攻击者可能滥用已泄露或者已被拦截的令牌的时长。
- 性能:较短的 TTL 意味着您的应用将更频繁地执行证明操作。由于应用证明过程会在每次执行时增加网络请求的延迟时间,因此短 TTL 可能会影响应用的性能。
对于大多数应用而言,默认的 TTL(1 小时)比较合理。
后续步骤
现在您已实现自定义提供程序的服务器端逻辑,接下来请了解如何通过 Apple、Android 和 Web 客户端使用该逻辑。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-23。
[null,null,["最后更新时间 (UTC):2025-08-23。"],[],[],null,["App Check has built-in support for several providers: DeviceCheck and App\nAttest on Apple platforms, Play Integrity on Android, and reCAPTCHA Enterprise\nin web apps ([overview](/docs/app-check)). These are well-understood providers\nthat should meet the needs of most developers. You can, however, also implement\nyour own custom App Check providers. Using a custom provider is necessary\nwhen:\n\n- You want to use a provider other than the built-in ones.\n\n- You want to use the built-in providers in unsupported ways.\n\n- You want to verify devices using platforms other than Apple, Android, and the\n web. For example, you could create App Check providers for desktop OSes or\n Internet-of-Things devices.\n\n- You want to implement your own verification techniques on any platform.\n\nOverview\n\nTo implement a custom App Check provider, you need a secure backend\nenvironment that can run the Node.js [Firebase Admin SDK](/docs/admin/setup).\nThis can be Cloud Functions, a container platform such as\n[Cloud Run](https://cloud.google.com/run), or your own server.\n\nFrom this environment, you will provide a network-accessible service that\nreceives proof of authenticity from your app clients, and---if the proof of\nauthenticity passes your authenticity assessment---returns an App Check\ntoken. The specific indicators you use as proof of authenticity will depend on\neither the third-party provider you're using, or the indicators of your own\ninvention, if you're implementing custom logic.\n\nUsually, you expose this service as a REST or gRPC endpoint, but this detail is\nup to you.\n\nCreate the token acquisition endpoint\n\n1. [Install and initialize the Admin SDK](/docs/admin/setup).\n\n2. Create a network-accessible endpoint that can receive authenticity data from\n your clients. For example, using Cloud Functions:\n\n // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken\n exports.fetchAppCheckToken = functions.https.onRequest((request, response) =\u003e {\n // ...\n });\n\n3. Add to the endpoint logic that assesses the authenticity data. This is the\n core logic of your custom App Check provider, which you will need to\n write yourself.\n\n4. If you determine the client to be authentic, use the Admin SDK to mint\n an App Check token and return it and its expiration time to the client:\n\n const admin = require('firebase-admin');\n admin.initializeApp();\n\n // ...\n\n admin.appCheck().createToken(appId)\n .then(function (appCheckToken) {\n // Token expires in an hour.\n const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;\n\n // Return appCheckToken and expiresAt to the client.\n })\n .catch(function (err) {\n console.error('Unable to create App Check token.');\n console.error(err);\n });\n\n | **Note:** If you encounter a token signing error while creating a new token, make sure your service account has the required permissions. See the [Admin SDK troubleshooting guide](/docs/auth/admin/create-custom-tokens#troubleshooting).\n\n If you can't verify the client's authenticity, return an error (for example,\n return an HTTP 403 error).\n5. **Optional** : Set the time-to-live (TTL) for App Check tokens issued by\n your custom provider by passing an `AppCheckTokenOptions` object to\n `createToken()`. You can set the TTL to any value between 30 minutes and 7\n days. When setting this value, be aware of the following tradeoffs:\n\n - Security: Shorter TTLs provide stronger security, because it reduces the window in which a leaked or intercepted token can be abused by an attacker.\n - Performance: Shorter TTLs mean your app will perform attestation more frequently. Because the app attestation process adds latency to network requests every time it's performed, a short TTL can impact the performance of your app.\n\n The default TTL of 1 hour is reasonable for most apps.\n\nNext steps\n\nNow that you've implemented your custom provider's server-side logic, learn how\nto use it from your [Apple](/docs/app-check/ios/custom-provider),\n[Android](/docs/app-check/android/custom-provider), and [web](/docs/app-check/web/custom-provider) clients."]]