Implémenter un fournisseur App Check personnalisé

App Check est compatible avec plusieurs fournisseurs : DeviceCheck et App Attest sur les plates-formes Apple, Play Integrity sur Android et reCAPTCHA Enterprise dans les applications Web (présentation). Il s'agit de fournisseurs bien connus qui devraient répondre aux besoins de la plupart des développeurs. Vous pouvez toutefois implémenter vos propres fournisseurs App Check personnalisés. L'utilisation d'un fournisseur personnalisé est nécessaire dans les cas suivants :

• Vous souhaitez utiliser un fournisseur autre que ceux intégrés.

• Vous souhaitez utiliser les fournisseurs intégrés de manière non compatible.

• Vous souhaitez valider des appareils à l'aide de plates-formes autres qu'Apple, Android et le Web. Par exemple, vous pouvez créer des fournisseurs App Check pour les systèmes d'exploitation de bureau ou les appareils IoT.

• Vous souhaitez implémenter vos propres techniques de validation sur n'importe quelle plate-forme.

Présentation

Pour implémenter un fournisseur App Check personnalisé, vous avez besoin d'un environnement backend sécurisé pouvant exécuter le Firebase Admin SDK pour Node.js. Il peut s'agir de Cloud Functions, d'une plate-forme de conteneurs telle que Cloud Run ou de votre propre serveur.

Dans cet environnement, vous fournirez un service accessible via le réseau qui reçoit une preuve d'authenticité de vos clients d'application et, si la preuve d' authenticité réussit votre évaluation de l'authenticité, renvoie un App Check jeton. Les indicateurs spécifiques que vous utilisez comme preuve d'authenticité dépendent du fournisseur tiers que vous utilisez ou des indicateurs que vous avez inventés si vous implémentez une logique personnalisée.

En règle générale, vous exposez ce service en tant que point de terminaison REST ou gRPC, mais ce détail vous appartient.

Créer le point de terminaison d'acquisition de jetons

1. Installez et initialisez le Admin SDK.

2. Créez un point de terminaison accessible via le réseau qui peut recevoir des données d'authenticité de vos clients. Exemple avec Cloud Functions :

   // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
   exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
     // ...
   });
   

3. Ajoutez à la logique du point de terminaison qui évalue les données d'authenticité. Il s'agit de la logique de base de votre fournisseur App Check personnalisé, que vous devrez écrire vous-même.

4. Si vous déterminez que le client est authentique, utilisez le Admin SDK pour générer un jeton App Check et le renvoyer au client avec son délai d'expiration :

   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);
      });
   

   Remarque : Si vous rencontrez une erreur de signature de jeton lors de la création d'un jeton, assurez-vous que votre compte de service dispose des autorisations requises. Consultez le guide de dépannage Admin SDK.

   Si vous ne parvenez pas à valider l'authenticité du client, renvoyez une erreur (par exemple, une erreur HTTP 403).

5. Facultatif : Définissez la durée de vie (TTL) des jetons App Check émis par votre fournisseur personnalisé en transmettant un objet AppCheckTokenOptions à createToken(). Vous pouvez définir la durée de vie sur n'importe quelle valeur comprise entre 30 minutes et 7 jours. Lorsque vous définissez cette valeur, tenez compte des compromis suivants :

   • Sécurité : des durées de vie plus courtes offrent une meilleure sécurité, car elles réduisent la fenêtre dans laquelle un jeton divulgué ou intercepté peut être utilisé à mauvais escient par un pirate informatique.
   • Performances : des durées de vie plus courtes signifient que votre application effectuera l'attestation plus fréquemment. Étant donné que le processus d'attestation de l'application ajoute une latence aux requêtes réseau chaque fois qu'il est effectué, une durée de vie courte peut avoir un impact sur les performances de votre application.

   La durée de vie par défaut d'une heure est raisonnable pour la plupart des applications.

Étapes suivantes

Maintenant que vous avez implémenté la logique côté serveur de votre fournisseur personnalisé, découvrez comment l'utiliser à partir de vos clients Apple, Android et Web.