Wdrażanie niestandardowego dostawcy Sprawdzania aplikacji
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
App Check ma wbudowaną obsługę kilku dostawców: DeviceCheck i AppAttest na platformach Apple, Play Integrity na Androidzie oraz reCAPTCHA Enterprise w aplikacjach internetowych (omówienie). Są to znani dostawcy, którzy powinni spełniać potrzeby większości deweloperów. Możesz jednak też wdrożyć własnych dostawców App Check. Korzystanie z niestandardowego dostawcy jest konieczne, gdy:
Chcesz użyć dostawcy innego niż wbudowany.
Chcesz używać wbudowanych dostawców w nieobsługiwany sposób.
Chcesz weryfikować urządzenia korzystające z platform innych niż Apple, Android i internet. Możesz na przykład utworzyć App Checkdostawców systemów operacyjnych na komputery lub urządzeń internetu rzeczy.
Chcesz wdrożyć własne techniki weryfikacji na dowolnej platformie.
Przegląd
Aby wdrożyć niestandardowego dostawcę App Check, potrzebujesz bezpiecznego środowiska backendu, w którym można uruchomić Firebase Admin SDK Node.js.
Może to być Cloud Functions platforma kontenerów, np. Cloud Run, lub Twój własny serwer.
W tym środowisku udostępnisz usługę dostępną w sieci, która będzie otrzymywać od klientów aplikacji dowód autentyczności i – jeśli dowód autentyczności przejdzie ocenę autentyczności – zwracać App Checktoken. Konkretne wskaźniki, których używasz jako dowodu autentyczności, zależą od dostawcy zewnętrznego, z którego usług korzystasz, lub od wskaźników, które sam wymyślisz, jeśli wdrażasz niestandardową logikę.
Zwykle udostępniasz tę usługę jako punkt końcowy REST lub gRPC, ale to zależy od Ciebie.
Tworzenie punktu końcowego uzyskiwania tokena
Zainstaluj i zainicjuj Admin SDK.
Utwórz punkt końcowy dostępny w sieci, który może odbierać dane o autentyczności od Twoich klientów. Na przykład używając Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
// ...
});
Dodaj do logiki punktu końcowego, która ocenia dane uwierzytelniające. Jest to podstawowa logika niestandardowego dostawcy App Check, którą musisz napisać samodzielnie.
Jeśli stwierdzisz, że klient jest autentyczny, użyj Admin SDK, aby wygenerować token App Check i zwrócić go wraz z czasem wygaśnięcia do klienta:
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);
});
Jeśli nie możesz zweryfikować autentyczności klienta, zwróć błąd (np. błąd HTTP 403).
Opcjonalnie: ustaw czas życia danych (TTL) dla tokenów App Check wydawanych przez niestandardowego dostawcę, przekazując obiekt AppCheckTokenOptions do funkcji createToken(). Wartość TTL możesz ustawić w zakresie od 30 minut do 7 dni. Ustawiając tę wartość, pamiętaj o tych kompromisach:
- Bezpieczeństwo: krótsze czasy TTL zapewniają większe bezpieczeństwo, ponieważ skracają okres, w którym wyciekły lub przechwycony token może zostać wykorzystany przez atakującego.
- Wydajność: krótsze czasy TTL oznaczają, że aplikacja będzie częściej przeprowadzać atestowanie. Proces potwierdzania aplikacji za każdym razem, gdy jest wykonywany, zwiększa opóźnienie w przypadku żądań sieciowych, dlatego krótki czas TTL może mieć wpływ na wydajność aplikacji.
Domyślna wartość TTL wynosząca 1 godzinę jest odpowiednia w przypadku większości aplikacji.
Dalsze kroki
Po wdrożeniu logiki po stronie serwera niestandardowego dostawcy dowiedz się, jak używać jej w klientach Apple, Android i internetowych.
O ile nie stwierdzono inaczej, treść tej strony jest objęta licencją Creative Commons – uznanie autorstwa 4.0, a fragmenty kodu są dostępne na licencji Apache 2.0. Szczegółowe informacje na ten temat zawierają zasady dotyczące witryny Google Developers. Java jest zastrzeżonym znakiem towarowym firmy Oracle i jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-08-23 UTC.
[null,null,["Ostatnia aktualizacja: 2025-08-23 UTC."],[],[],null,["# Implement a custom App Check provider\n\nApp 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--------\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-------------------------------------\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----------\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."]]
