App Checkには、AppleプラットフォームでのDeviceCheckとApp Attest、AndroidでのPlay IntegrityとSafetyNet、WebアプリでのreCAPTCHAv3とreCAPTCHAEnterpriseなどのいくつかのプロバイダーのサポートが組み込まれています。 (概要)。これらは、ほとんどの開発者のニーズを満たすはずのよく理解されているプロバイダーです。ただし、独自のカスタムAppCheckプロバイダーを実装することもできます。カスタムプロバイダーを使用する必要があるのは、次の場合です。
組み込み以外のプロバイダーを使用したい。
サポートされていない方法で組み込みプロバイダーを使用したい。
Apple、Android、およびWeb以外のプラットフォームを使用してデバイスを検証する必要があります。たとえば、デスクトップOSまたはモノのインターネットデバイス用のAppCheckプロバイダーを作成できます。
独自の検証手法を任意のプラットフォームに実装したいと考えています。
概要
カスタムAppCheckプロバイダーを実装するには、Node.js FirebaseAdminSDKを実行できる安全なバックエンド環境が必要です。これは、Cloud Functions、 Cloud Runなどのコンテナプラットフォーム、または独自のサーバーにすることができます。
この環境から、アプリクライアントから真正性の証明を受け取るネットワークアクセス可能なサービスを提供し、真正性の証明が真正性評価に合格した場合は、AppCheckトークンを返します。真正性の証明として使用する特定のインジケーターは、使用しているサードパーティプロバイダー、またはカスタムロジックを実装している場合は、独自の発明のインジケーターのいずれかに依存します。
通常、このサービスをRESTまたはgRPCエンドポイントとして公開しますが、この詳細はあなた次第です。
トークン取得エンドポイントを作成します
クライアントから信頼性データを受信できるネットワークアクセス可能なエンドポイントを作成します。たとえば、CloudFunctionsを使用します。
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken exports.fetchAppCheckToken = functions.https.onCall((authenticityData, context) => { // ... });
信頼性データを評価するエンドポイントロジックに追加します。これは、カスタムApp Checkプロバイダーのコアロジックであり、自分で作成する必要があります。
クライアントが本物であると判断した場合は、Admin SDKを使用してAppCheckトークンを作成し、それとその有効期限をクライアントに返します。
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 、およびWebクライアントからそれを使用する方法を学びます。