Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
App Check bietet integrierte Unterstützung für mehrere Anbieter: DeviceCheck und AppAttest auf Apple-Plattformen, Play Integrity auf Android und reCAPTCHA Enterprise in Web-Apps (Übersicht). Diese Anbieter sind gut bekannt und sollten die Anforderungen der meisten Entwickler erfüllen. Sie können jedoch auch eigene benutzerdefinierte App Check-Anbieter implementieren. Die Verwendung eines benutzerdefinierten Providers ist in folgenden Fällen erforderlich:
Sie möchten einen anderen Anbieter als die integrierten verwenden.
Sie möchten die integrierten Anbieter auf nicht unterstützte Weise verwenden.
Sie möchten Geräte mit anderen Plattformen als Apple, Android und dem Web bestätigen. Sie können beispielsweise App Check-Anbieter für Desktop-Betriebssysteme oder IoT-Geräte erstellen.
Sie möchten eigene Bestätigungstechniken auf einer beliebigen Plattform implementieren.
Übersicht
Wenn Sie einen benutzerdefinierten App Check-Anbieter implementieren möchten, benötigen Sie eine sichere Backend-Umgebung, in der die Node.js-Firebase Admin SDK ausgeführt werden kann.
Das kann Cloud Functions, eine Containerplattform wie Cloud Run oder Ihr eigener Server sein.
In dieser Umgebung stellen Sie einen über das Netzwerk zugänglichen Dienst bereit, der den Authentizitätsnachweis von Ihren App-Clients empfängt und – wenn der Authentizitätsnachweis Ihre Authentizitätsprüfung besteht – ein App Check-Token zurückgibt. Welche Indikatoren Sie als Authentizitätsnachweis verwenden, hängt entweder vom Drittanbieter ab, den Sie nutzen, oder von den Indikatoren, die Sie selbst entwickeln, wenn Sie benutzerdefinierte Logik implementieren.
Normalerweise stellen Sie diesen Dienst als REST- oder gRPC-Endpunkt bereit.
Erstellen Sie einen über das Netzwerk zugänglichen Endpunkt, der Authentizitätsdaten von Ihren Clients empfangen kann. Verwenden Sie zum Beispiel Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckTokenexports.fetchAppCheckToken=functions.https.onRequest((request,response)=>{// ...});
Fügen Sie der Endpunktlogik hinzu, mit der die Authentizitätsdaten bewertet werden. Dies ist die Kernlogik Ihres benutzerdefinierten App Check-Anbieters, die Sie selbst schreiben müssen.
Wenn Sie feststellen, dass der Client authentisch ist, verwenden Sie Admin SDK, um ein App Check-Token zu erstellen und es zusammen mit der Ablaufzeit an den Client zurückzugeben:
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);});
Wenn Sie die Authentizität des Clients nicht bestätigen können, geben Sie einen Fehler zurück (z. B. einen HTTP-Fehler 403).
Optional: Legen Sie die Gültigkeitsdauer (TTL) für App Check-Tokens fest, die von Ihrem benutzerdefinierten Anbieter ausgestellt werden, indem Sie ein AppCheckTokenOptions-Objekt an createToken() übergeben. Sie können die TTL auf einen beliebigen Wert zwischen 30 Minuten und 7 Tagen festlegen. Beachten Sie beim Festlegen dieses Werts die folgenden Kompromisse:
Sicherheit: Kürzere TTLs bieten mehr Sicherheit, da sie das Zeitfenster verringern, in dem ein geleaktes oder abgefangenes Token von einem Angreifer missbraucht werden kann.
Leistung: Bei kürzeren TTLs wird die Gerätebestätigung in Ihrer App häufiger ausgeführt. Da der Prozess zur App-Attestierung bei jeder Ausführung die Latenz von Netzwerkanfragen erhöht, kann sich eine kurze TTL auf die Leistung Ihrer App auswirken.
Die Standard-TTL von 1 Stunde ist für die meisten Apps angemessen.
Nächste Schritte
Nachdem Sie die serverseitige Logik Ihres benutzerdefinierten Anbieters implementiert haben, erfahren Sie hier, wie Sie sie von Ihren Apple-, Android- und Web-Clients aus verwenden.
[null,null,["Zuletzt aktualisiert: 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."]]
