Sprawdzanie aplikacji ma wbudowaną obsługę kilku dostawców: DeviceCheck i App Attest. na platformach Apple, Play Integrity i SafetyNet na Androidzie, i reCAPTCHA Enterprise w aplikacjach internetowych (omówienie). Są to dobrze zrozumieni dostawcy, którzy powinni spełniać potrzeby większości dla programistów. Możesz też wdrożyć własne niestandardowe Sprawdzanie aplikacji dostawców usług. Korzystanie z dostawcy niestandardowego 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 na platformach innych niż Apple, Android sieci. Możesz na przykład utworzyć dostawców Sprawdzania aplikacji dla komputerowych systemów operacyjnych lub Urządzenia korzystające z internetu rzeczy.
chcesz wdrożyć własne techniki weryfikacji na dowolnej platformie;
Omówienie
Aby wdrożyć dostawcę niestandardowego Sprawdzanie aplikacji, potrzebujesz bezpiecznego backendu w którym możesz uruchamiać pakiet Node.js Firebase Admin SDK. Może to być Cloud Functions, platforma kontenerowa, taka jak Cloud Run lub własny serwer.
W tym środowisku zapewnisz dostępną przez sieć usługę, która otrzyma potwierdzenie autentyczności od klientów aplikacji, a jeśli dowód autentyczność musi przejść Twoją ocenę autentyczności – zwraca funkcję Sprawdzanie aplikacji token. Konkretne wskaźniki, których użyjesz jako potwierdzenia autentyczności, będą zależeć od zewnętrznego usługodawcy, z którego usług korzystasz, lub Twoich wskaźników, jeśli korzystasz z logiki niestandardowej.
Zazwyczaj udostępniasz tę usługę jako punkt końcowy REST lub gRPC, ale ten szczegół jest do Ciebie.
Tworzenie punktu końcowego pozyskiwania tokenów
Utwórz dostępny przez sieć punkt końcowy, który może otrzymywać dane autentyczności z Twoim klientom. Na przykład za pomocą Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken exports.fetchAppCheckToken = functions.https.onRequest((request, response) => { // ... });Dodaj do logiki punktu końcowego ocenę danych autentyczności. To jest logikę dostawcy niestandardowego Sprawdzania aplikacji, którą należy napisz o sobie.
Jeśli stwierdzisz, że klient jest autentyczny, użyj pakietu Admin SDK, aby wygenerować token Sprawdzania aplikacji i zwraca go klientowi wraz z czasem wygaśnięcia:
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 (na przykład zwraca błąd HTTP 403).
Opcjonalnie: ustaw czas życia (TTL) tokenów Sprawdzania aplikacji wydanych przez do dostawcy niestandardowego, przekazując obiekt
AppCheckTokenOptionsdocreateToken()TTL możesz ustawić na dowolną wartość z zakresu od 30 minut do 7. dni. Ustawiając tę wartość, pamiętaj o tych wadach:- Bezpieczeństwo: krótsze wartości TTL zapewniają silniejsze zabezpieczenia, ponieważ zmniejszają okno, w którym ujawniony lub przechwycony token może zostać wykorzystany przez atakującego.
- Wydajność: krótsze wartości TTL oznaczają większą wydajność atestu aplikacji często. Ponieważ proces poświadczania aplikacji zwiększa opóźnienie sieci. żądań przy każdym wykonaniu, krótki czas TTL może wpływać na wydajność Twojej aplikacji.
Domyślny TTL wynoszący 1 godzinę jest rozsądny w przypadku większości aplikacji.
Dalsze kroki
Po zaimplementowaniu logiki dostawcy niestandardowego po stronie serwera dowiedz się, jak aby móc go używać na urządzeniu Apple, Klienty na Androida i internetowe.