App Check 內建支援以下數個供應商:DeviceCheck 和 App Attest 包括 Android 上的 Play Integrity 和 SafetyNet 和 reCAPTCHA Enterprise (總覽)。 這些是專業的供應商,能滿足大多數企業的需求 開發人員。但您也可以導入自己的自訂 App Check 以滿足需求下列情況需要使用自訂提供者:
您想使用內建服務供應商以外的提供者。
您想以不支援的方式使用內建供應商。
您想使用 Apple、Android 和 網頁。舉例來說,您可以建立適用於桌上型電腦 OS 的 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()
。存留時間可設為 30 分鐘至 7 之間的任何值 天。設定這個值時,請注意以下優缺點:- 安全性:較短的存留時間可提高安全性,因為這麼做能減少 出現安全漏洞,可能導致權杖遭到洩漏或攔截 攻擊者
- 效能:縮短存留時間 (TTL) 越短,應用程式就越能執行認證 經常更新因為應用程式認證程序會增加網路延遲時間 因此短暫的存留時間 (TTL) 可能會影響效能
對大多數應用程式來說,預設的存留時間是 1 小時。
後續步驟
現在您已實作自訂提供者的伺服器端邏輯,接下來請學習如何使用 並透過 Apple 使用。 Android 和網路用戶端。