App Check ma wbudowaną obsługę kilku dostawców: DeviceCheck i App Attest na platformach Apple, Play Integrity i SafetyNet na Androida oraz reCAPTCHA v3 i reCAPTCHA Enterprise w aplikacjach internetowych ( omówienie ). Są to dobrze rozumiani dostawcy, którzy powinni zaspokoić potrzeby większości programistów. Możesz jednak również zaimplementować własnych niestandardowych dostawców sprawdzania aplikacji. 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 zweryfikować urządzenia korzystające z platform innych niż Apple, Android i internet. Możesz na przykład utworzyć dostawców sprawdzania aplikacji dla systemów operacyjnych komputerów stacjonarnych lub urządzeń Internetu rzeczy.
Chcesz wdrożyć własne techniki weryfikacji na dowolnej platformie.
Przegląd
Aby zaimplementować niestandardowego dostawcę sprawdzania aplikacji, potrzebujesz bezpiecznego środowiska zaplecza, w którym można uruchomić pakiet Node.js Firebase Admin SDK . Może to być Cloud Functions, platforma kontenerowa, taka jak Cloud Run lub Twój własny serwer.
Z tego środowiska zapewnisz usługę dostępną w sieci, która otrzyma dowód autentyczności od klientów aplikacji i — jeśli dowód autentyczności przejdzie pomyślnie Twoją ocenę autentyczności — zwróci token sprawdzania aplikacji. Konkretne wskaźniki używane jako dowód autentyczności będą zależeć od dostawcy zewnętrznego, z którego korzystasz, lub wskaźników własnego wynalazku, jeśli implementujesz logikę niestandardową.
Zwykle ujawniasz tę usługę jako punkt końcowy REST lub gRPC, ale ten szczegół zależy od Ciebie.
Utwórz punkt końcowy pozyskiwania tokenów
Utwórz dostępny w sieci punkt końcowy, który może odbierać dane dotyczące autentyczności od klientów. Na przykład za pomocą Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken exports.fetchAppCheckToken = functions.https.onCall((authenticityData, context) => { // ... });Dodaj do logiki punktu końcowego, która ocenia dane autentyczności. Jest to podstawowa logika Twojego niestandardowego dostawcy sprawdzania aplikacji, którą musisz napisać samodzielnie.
Jeśli stwierdzisz, że klient jest autentyczny, użyj pakietu Admin SDK, aby wybić token sprawdzania aplikacji i zwrócić go wraz z czasem wygaśnięcia klientowi:
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 zwróć błąd HTTP 403).
Opcjonalnie : Ustaw czas wygaśnięcia (TTL) dla tokenów sprawdzania aplikacji wystawionych przez niestandardowego dostawcę, przekazując obiekt
AppCheckTokenOptionsdocreateToken(). TTL można ustawić na dowolną wartość z zakresu od 30 minut do 7 dni. Podczas ustawiania tej wartości należy pamiętać o następujących kompromisach:- Bezpieczeństwo: krótsze TTL zapewniają większe bezpieczeństwo, ponieważ skracają okno, w którym wyciekający lub przechwycony token może zostać wykorzystany przez atakującego.
- Wydajność: krótsze TTL oznaczają, że Twoja aplikacja będzie częściej przeprowadzać atestację. Ponieważ proces zaświadczania aplikacji dodaje opóźnienia do żądań sieciowych za każdym razem, gdy jest wykonywany, krótki TTL może mieć wpływ na wydajność Twojej aplikacji.
Domyślny czas TTL wynoszący 1 godzinę jest rozsądny w przypadku większości aplikacji.
Następne kroki
Teraz, po zaimplementowaniu logiki po stronie serwera niestandardowego dostawcy, dowiedz się, jak z niej korzystać na swoich klientach Apple , Android i internetowych .