App Check カスタム プロバイダを実装する

App Check には、複数のプロバイダに対するサポートが組み込まれています。Apple プラットフォームでは DeviceCheck と App Attest、Android では Play Integrity、ウェブアプリでは reCAPTCHA Enterprise がそれぞれサポートされています（概要）。ほとんどのデベロッパーの要件は、これらはプロバイダで満たすことができますが、独自の App Check カスタム プロバイダを実装することもできます。次のような場合には、カスタム プロバイダが必要になります。

  • 組み込みのプロバイダ以外のプロバイダを使用したい。

  • サポートされていない方法で組み込みのプロバイダを使用したい。

  • Apple、Android、ウェブ以外のプラットフォームを使用するデバイスを確認したい。たとえば、デスクトップ OS や IoT（モノのインターネット）デバイス用に App Check プロバイダを作成する場合など。

  • どのプラットフォームにも独自の検証技術を実装したい。

概要

カスタム App Check プロバイダを実装するには、Node.js Firebase Admin SDK を実行できる安全なバックエンド環境が必要です。このような環境としては、Cloud Functions、Cloud Run などのコンテナ プラットフォーム、独自のサーバーなどがあります。

この環境で、ネットワークを介してアプリ クライアントから真正性の証明書を受け取り、真正性が証明された場合に App Check トークンを返すサービスを用意します。真正性の証明として使用できるインジケーターは、使用しているサードパーティ プロバイダによって異なります。また、カスタム ロジックを実装する場合は、独自のインジケーターを構築する必要があります。

通常、このサービスは REST エンドポイントまたは gRPC エンドポイントとして公開しますが、その詳細はデベロッパーが決定します。

トークン取得エンドポイントを作成する

  1. Admin SDK をインストールして初期化します。

  2. クライアントから真正性データをネットワーク経由で受信するエンドポイントを作成します。Cloud Functions の使用例を次に示します。

    // 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. 省略可: createToken() オブジェクトを AppCheckTokenOptions に渡して、カスタム プロバイダによって発行される App Check トークンの有効期間（TTL）を設定します。TTL は 30 分から 7 日までの任意の値に設定できます。この値を設定する場合は、次のトレードオフに注意してください。

    • セキュリティ: TTL が短いほど、漏えいしたトークンや傍受されたトークンが攻撃者によって悪用される可能性が低減するため、セキュリティが向上します。
    • パフォーマンス: TTL が短いほど、アプリで証明書の取得が頻繁に行われます。アプリで証明書が取得されるたびにネットワーク リクエストのレイテンシが増加するため、TTL が短いと、アプリのパフォーマンスに影響する可能性があります。

    通常は、デフォルトの TTL（1 時間）で十分です。

次のステップ

ここでは、カスタム プロバイダのサーバー側のロジックを実装しました。次に、このロジックを Apple、Android、ウェブ クライアントから使用する方法を学習します。