導入自訂 App Check 供應商
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
App Check 內建支援多個供應商:Apple 平台上的 DeviceCheck 和 AppAttest、Android 上的 Play Integrity,以及網頁應用程式中的 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)。您可以將存留時間設為介於 30 分鐘至 7 天之間的任何值。設定這個值時,請注意下列取捨:
- 安全性:存留時間越短,安全性就越高,因為這樣可縮短攻擊者濫用外洩或遭攔截權杖的時間範圍。
- 效能:TTL 較短表示應用程式會更頻繁地執行認證。應用程式認證程序每次執行時,都會增加網路要求延遲時間,因此 TTL 較短可能會影響應用程式效能。
預設存留時間為 1 小時,適用於大多數應用程式。
後續步驟
您已實作自訂供應商的伺服器端邏輯,接下來請參閱如何從 Apple、Android 和網頁用戶端使用這項邏輯。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-23 (世界標準時間)。
[null,null,["上次更新時間: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."]]