實作自訂 App Check 提供者

App Check 內建了對多個提供者的支援:Apple 平台上的 DeviceCheck 和 App Attest、Android 上的 Play Integrity 和 SafetyNet 以及 Web 應用程式中的 reCAPTCHA Enterprise(概述)。這些都是易於理解的提供程序,應該可以滿足大多數開發人員的需求。但是,您也可以實作自己的自訂應用程式檢查提供者。在以下情況下需要使用自訂提供者:

  • 您想要使用內建提供者以外的提供者。

  • 您希望以不支援的方式使用內建提供者。

  • 您想要使用 Apple、Android 和 Web 以外的平台驗證裝置。例如,您可以為桌面作業系統或物聯網裝置建立 App Check 提供者。

  • 您希望在任何平台上實施您自己的驗證技術。

概述

要實作自訂 App Check 提供程序,您需要一個可以執行 Node.js Firebase Admin SDK 的安全後端環境。這可以是 Cloud Functions、 Cloud Run等容器平台或您自己的伺服器。

在此環境中,您將提供可透過網路存取的服務,該服務從應用程式用戶端接收真實性證明,並且如果真實性證明通過了真實性評估,則傳回 App Check 令牌。您用作真實性證明的具體指標將取決於您正在使用的第三方提供者,或您自己發明的指標(如果您正在實施自訂邏輯)。

通常,您將此服務公開為 REST 或 gRPC 端點,但此細節取決於您。

建立令牌獲取端點

  1. 安裝並初始化管理 SDK

  2. 建立可從用戶端接收真實性資料的網路可存取端點。例如,使用雲端函數:

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
    exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
      // ...
    });
    
  3. 新增到評估真實性資料的端點邏輯。這是自訂 App Check 提供者的核心邏輯,您需要自己編寫。

  4. 如果您確定客戶端是可信任的,請使用 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 錯誤)。

  5. 可選:透過將AppCheckTokenOptions物件傳遞給createToken()來設定自訂提供者所頒發的 App Check 令牌的生存時間 (TTL)。您可以將 TTL 設定為 30 分鐘到 7 天之間的任意值。設定此值時,請注意以下權衡:

    • 安全性:較短的 TTL 提供更強的安全性,因為它減少了攻擊者濫用洩漏或攔截的令牌的視窗。
    • 效能:較短的 TTL 意味著您的應用程式將更頻繁地執行證明。由於應用程式證明過程會在每次執行時增加網路請求的延遲,因此較短的 TTL 可能會影響應用程式的效能。

    對於大多數應用程式來說,預設 TTL 1 小時是合理的。

下一步

現在您已經實作了自訂提供者的伺服器端邏輯,接下來了解如何從AppleAndroidWeb用戶端使用它。

,

App Check 內建了對多個提供者的支援:Apple 平台上的 DeviceCheck 和 App Attest、Android 上的 Play Integrity 和 SafetyNet 以及 Web 應用程式中的 reCAPTCHA Enterprise(概述)。這些都是易於理解的提供程序,應該可以滿足大多數開發人員的需求。但是,您也可以實作自己的自訂應用程式檢查提供者。在以下情況下需要使用自訂提供者:

  • 您想要使用內建提供者以外的提供者。

  • 您希望以不支援的方式使用內建提供者。

  • 您想要使用 Apple、Android 和 Web 以外的平台驗證裝置。例如,您可以為桌面作業系統或物聯網裝置建立 App Check 提供者。

  • 您希望在任何平台上實施您自己的驗證技術。

概述

要實作自訂 App Check 提供程序,您需要一個可以執行 Node.js Firebase Admin SDK 的安全後端環境。這可以是 Cloud Functions、 Cloud Run等容器平台或您自己的伺服器。

在此環境中,您將提供可透過網路存取的服務,該服務從應用程式用戶端接收真實性證明,並且如果真實性證明通過了真實性評估,則傳回 App Check 令牌。您用作真實性證明的具體指標將取決於您正在使用的第三方提供者,或您自己發明的指標(如果您正在實施自訂邏輯)。

通常,您將此服務公開為 REST 或 gRPC 端點,但此細節取決於您。

建立令牌獲取端點

  1. 安裝並初始化管理 SDK

  2. 建立可從用戶端接收真實性資料的網路可存取端點。例如,使用雲端函數:

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
    exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
      // ...
    });
    
  3. 新增到評估真實性資料的端點邏輯。這是自訂 App Check 提供者的核心邏輯,您需要自己編寫。

  4. 如果您確定客戶端是可信任的,請使用 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 錯誤)。

  5. 可選:透過將AppCheckTokenOptions物件傳遞給createToken()來設定自訂提供者所頒發的 App Check 令牌的生存時間 (TTL)。您可以將 TTL 設定為 30 分鐘到 7 天之間的任意值。設定此值時,請注意以下權衡:

    • 安全性:較短的 TTL 提供更強的安全性,因為它減少了攻擊者濫用洩漏或攔截的令牌的視窗。
    • 效能:較短的 TTL 意味著您的應用程式將更頻繁地執行證明。由於應用程式證明過程會在每次執行時增加網路請求的延遲,因此較短的 TTL 可能會影響應用程式的效能。

    對於大多數應用程式來說,預設 TTL 1 小時是合理的。

下一步

現在您已經實作了自訂提供者的伺服器端邏輯,接下來了解如何從AppleAndroidWeb用戶端使用它。