Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
App Check est compatible avec plusieurs fournisseurs : DeviceCheck et AppAttest 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. Toutefois, vous pouvez également implémenter vos propres fournisseurs App Check personnalisés. Il est nécessaire d'utiliser un fournisseur personnalisé 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 OS 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 de backend sécurisé pouvant exécuter le Firebase Admin SDK 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 sur le réseau qui reçoit une preuve d'authenticité de vos applications clientes et, si la preuve d'authenticité réussit votre évaluation de l'authenticité, renvoie un jeton App Check. 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
Créez un point de terminaison accessible au réseau qui peut recevoir des données d'authenticité de vos clients. Exemple, à l'aide de Cloud Functions :
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckTokenexports.fetchAppCheckToken=functions.https.onRequest((request,response)=>{// ...});
Ajoutez à la logique du point de terminaison les données d'évaluation de l'authenticité. Il s'agit de la logique de base de votre fournisseur de App Check personnalisé, que vous devrez écrire vous-même.
Si vous déterminez que le client est authentique, utilisez Admin SDK pour générer un jeton App Check et renvoyez-le ainsi que son délai d'expiration au client :
constadmin=require('firebase-admin');admin.initializeApp();// ...admin.appCheck().createToken(appId).then(function(appCheckToken){// Token expires in an hour.constexpiresAt=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 parvenez pas à valider l'authenticité du client, renvoyez une erreur (par exemple, une erreur HTTP 403).
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 le TTL 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 valeurs TTL plus courtes offrent une sécurité renforcée, car elles réduisent la période pendant laquelle un jeton divulgué ou intercepté peut être utilisé à des fins malveillantes par un pirate informatique.
Performances : des valeurs TTL plus courtes signifient que votre application effectuera l'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 effectué, un TTL court 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.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/08/23 (UTC).
[null,null,["Dernière mise à jour le 2025/08/23 (UTC)."],[],[],null,["App Check has built-in support for several providers: DeviceCheck and App\nAttest on Apple platforms, Play Integrity on Android, and reCAPTCHA Enterprise\nin web apps ([overview](/docs/app-check)). These are well-understood providers\nthat should meet the needs of most developers. You can, however, also implement\nyour own custom App Check providers. Using a custom provider is necessary\nwhen:\n\n- You want to use a provider other than the built-in ones.\n\n- You want to use the built-in providers in unsupported ways.\n\n- You want to verify devices using platforms other than Apple, Android, and the\n web. For example, you could create App Check providers for desktop OSes or\n Internet-of-Things devices.\n\n- You want to implement your own verification techniques on any platform.\n\nOverview\n\nTo implement a custom App Check provider, you need a secure backend\nenvironment that can run the Node.js [Firebase Admin SDK](/docs/admin/setup).\nThis can be Cloud Functions, a container platform such as\n[Cloud Run](https://cloud.google.com/run), or your own server.\n\nFrom this environment, you will provide a network-accessible service that\nreceives proof of authenticity from your app clients, and---if the proof of\nauthenticity passes your authenticity assessment---returns an App Check\ntoken. The specific indicators you use as proof of authenticity will depend on\neither the third-party provider you're using, or the indicators of your own\ninvention, if you're implementing custom logic.\n\nUsually, you expose this service as a REST or gRPC endpoint, but this detail is\nup to you.\n\nCreate the token acquisition endpoint\n\n1. [Install and initialize the Admin SDK](/docs/admin/setup).\n\n2. Create a network-accessible endpoint that can receive authenticity data from\n your clients. For example, using Cloud Functions:\n\n // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken\n exports.fetchAppCheckToken = functions.https.onRequest((request, response) =\u003e {\n // ...\n });\n\n3. Add to the endpoint logic that assesses the authenticity data. This is the\n core logic of your custom App Check provider, which you will need to\n write yourself.\n\n4. If you determine the client to be authentic, use the Admin SDK to mint\n an App Check token and return it and its expiration time to the client:\n\n const admin = require('firebase-admin');\n admin.initializeApp();\n\n // ...\n\n admin.appCheck().createToken(appId)\n .then(function (appCheckToken) {\n // Token expires in an hour.\n const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;\n\n // Return appCheckToken and expiresAt to the client.\n })\n .catch(function (err) {\n console.error('Unable to create App Check token.');\n console.error(err);\n });\n\n | **Note:** If you encounter a token signing error while creating a new token, make sure your service account has the required permissions. See the [Admin SDK troubleshooting guide](/docs/auth/admin/create-custom-tokens#troubleshooting).\n\n If you can't verify the client's authenticity, return an error (for example,\n return an HTTP 403 error).\n5. **Optional** : Set the time-to-live (TTL) for App Check tokens issued by\n your custom provider by passing an `AppCheckTokenOptions` object to\n `createToken()`. You can set the TTL to any value between 30 minutes and 7\n days. When setting this value, be aware of the following tradeoffs:\n\n - Security: Shorter TTLs provide stronger security, because it reduces the window in which a leaked or intercepted token can be abused by an attacker.\n - Performance: Shorter TTLs mean your app will perform attestation more frequently. Because the app attestation process adds latency to network requests every time it's performed, a short TTL can impact the performance of your app.\n\n The default TTL of 1 hour is reasonable for most apps.\n\nNext steps\n\nNow that you've implemented your custom provider's server-side logic, learn how\nto use it from your [Apple](/docs/app-check/ios/custom-provider),\n[Android](/docs/app-check/android/custom-provider), and [web](/docs/app-check/web/custom-provider) clients."]]