App Check には、複数のプロバイダに対するサポートが組み込まれています。Apple プラットフォームでは DeviceCheck と App Attest、Android では Play Integrity と SafetyNet、ウェブアプリでは 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 エンドポイントとして公開しますが、その詳細はデベロッパーが決定します。
トークン取得エンドポイントを作成する
クライアントから真正性データをネットワーク経由で受信するエンドポイントを作成します。たとえば、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)を設定します。TTL は 30 分から 7 日までの任意の値に設定できます。この値を設定する場合は、次のトレードオフに注意してください。- セキュリティ: TTL が短いほど、漏えいしたトークンや傍受されたトークンが攻撃者によって悪用される可能性が低減するため、セキュリティが向上します。
- パフォーマンス: TTL が短いほど、アプリで証明書の取得が頻繁に行われます。アプリで証明書が取得されるたびにネットワーク リクエストのレイテンシが増加するため、TTL が短いと、アプリのパフォーマンスに影響する可能性があります。
通常は、デフォルトの TTL(1 時間)で十分です。
次のステップ
ここでは、カスタム プロバイダのサーバー側のロジックを実装しました。次に、このロジックを Apple、Android、ウェブ クライアントから使用する方法を学習します。