App Check 內建多種供應商的支援功能:Apple 平台的 DeviceCheck 和 App Attest、Android 的 Play Integrity,以及網頁應用程式中的 reCAPTCHA Enterprise (總覽)。這些供應商都廣為人知,應該能滿足大多數開發人員的需求。不過,您也可以實作自訂 App Check 供應器。在下列情況下,您必須使用自訂提供者:
您想使用內建供應器以外的供應器。
您想以不支援的方式使用內建供應器。
您想驗證 Apple、Android 和網頁以外平台的裝置。舉例來說,您可以為電腦作業系統或物聯網裝置建立 App Check 供應器。
您想在任何平台上實作自己的驗證技術。
總覽
如要實作自訂 App Check 供應器,您需要安全的後端環境,才能執行 Node.js Firebase Admin SDK。這可以是 Cloud Functions、Cloud Run 等容器平台,或您自己的伺服器。
在這個環境中,您會提供可透過網路存取的服務,從應用程式用戶端接收真實性證明,如果真實性證明通過您的真實性評估,就會傳回 App Check 權杖。您用來證明真實性的特定指標,取決於您使用的第三方供應商,或您自行發明的指標 (如果您要實作自訂邏輯)。
通常您會將這項服務公開為 REST 或 gRPC 端點,但這項細節由您自行決定。
建立權杖取得端點
建立可透過網路存取的端點,以便接收來自用戶端的真實性資料。例如使用 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 錯誤)。
選用:為自訂提供者核發的 App Check 權杖設定存留時間 (TTL),方法是將
AppCheckTokenOptions
物件傳遞至createToken()
。您可以將 TTL 設為 30 分鐘至 7 天之間的任何值。設定此值時,請注意下列權衡:- 安全性:縮短存留時間可提供更強的安全性,因為這樣一來,攻擊者就無法在較短的時間內濫用遭洩漏或攔截的權杖。
- 效能:TTL 越短,應用程式執行認證的頻率就越高。由於應用程式認證程序每次執行時都會為網路要求增加延遲時間,因此 TTL 時間過短可能會影響應用程式的效能。
預設的存留時間為 1 小時,適用於大多數應用程式。
後續步驟
您已實作自訂提供者的伺服器端邏輯,現在請瞭解如何在 Apple、Android 和 網路用戶端中使用這項邏輯。