Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

Implémenter un fournisseur App Check personnalisé

App Check a un support intégré pour plusieurs fournisseurs: DeviceCheck et App Certifier sur iOS, SafetyNet sur Android, ou reCAPTCHA v3 dans les applications Web ( aperçu ). Ce sont des fournisseurs bien compris qui devraient répondre aux besoins de la plupart des développeurs. Cependant, vous pouvez également implémenter vos propres fournisseurs App Check personnalisés. L'utilisation d'un fournisseur personnalisé est nécessaire lorsque :

  • Vous souhaitez utiliser un fournisseur autre que DeviceCheck ou App Attest sur iOS, SafetyNet sur Android ou reCAPTCHA dans les applications Web.

  • Vous souhaitez vérifier les appareils utilisant des plates-formes autres qu'iOS, 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 Internet des objets.

  • Vous souhaitez mettre en œuvre vos propres techniques de vérification sur n'importe quelle plateforme.

Aperçu

Pour mettre en œuvre une coutume App fournisseur de vérification, vous avez besoin d' un environnement sécurisé back - end qui peut exécuter le Node.js Firebase Administrateur SDK . Cela peut être des fonctions Nuage, une plate - forme de conteneur tel nuage Exécuter , ou votre propre serveur.

À partir de cet environnement, vous fournirez un service accessible par 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 d'authenticité, renvoie un jeton App Check. Les indicateurs spécifiques que vous utilisez comme preuve d'authenticité dépendront soit du fournisseur tiers que vous utilisez, soit des indicateurs de votre propre invention, si vous implémentez une logique personnalisée.

Généralement, 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. Installer et initialiser le Admin SDK .

  2. Créez un point de terminaison accessible sur le réseau qui peut recevoir des données d'authenticité de vos clients. Par exemple, en utilisant Cloud Functions :

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
    exports.fetchAppCheckToken = functions.https.onCall((authenticityData, context) => {
      // ...
    });
    
  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 SDK Admin pour créer un jeton App Check et le renvoyer ainsi que son délai d'expiration au client :

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

    Si vous ne pouvez pas vérifier l'authenticité du client, renvoyez une erreur (par exemple, renvoyez une erreur HTTP 403).

  5. En option: Réglez le temps de vie (TTL) pour App Vérifiez les jetons émis par votre fournisseur personnalisé en passant un AppCheckTokenOptions objet à createToken() . Vous pouvez définir le TTL sur n'importe quelle valeur comprise entre 30 minutes et 7 jours. Lors de la définition de cette valeur, tenez compte des compromis suivants :

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

    Le TTL par défaut de 1 heure est raisonnable pour la plupart des applications.

Prochaines étapes

Maintenant que vous avez mis votre logique côté serveur de fournisseur personnalisé, apprendre à l' utiliser de votre iOS , Android et Web clients.