App Check ma wbudowaną obsługę kilku dostawców: DeviceCheck i App Attest na platformach Apple, Play Integrity na Androidzie oraz reCAPTCHA Enterprise w aplikacjach internetowych (przegląd). Są to dobrze znani dostawcy, którzy powinni spełnić potrzeby większości programistów. Możesz jednak wdrożyć własnych niestandardowych App Check dostawców. Użycie 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 Check dostawców dla komputerowych systemów operacyjnych 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 backendowego , 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.
W tym środowisku udostępnisz usługę dostępną w sieci, która będzie otrzymywać dowody autentyczności od klientów Twojej aplikacji i – jeśli dowód autentyczności przejdzie ocenę autentyczności – zwracać token App Check. Konkretne wskaźniki używane jako dowód autentyczności będą zależeć od dostawcy zewnętrznego, z którego korzystasz, lub od wskaźników własnego pomysłu, 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
Utwórz punkt końcowy dostępny w sieci, który może odbierać dane 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.onRequest((request, response) => { // ... });Dodaj do punktu końcowego logikę, która ocenia dane autentyczności. Jest to podstawowa logika niestandardowego App Check dostawcy, 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 (TTL) tokenów App Check wydawanych przez niestandardowego dostawcę, przekazując obiekt
AppCheckTokenOptionsdocreateToken(). Możesz ustawić TTL na dowolną wartość od 30 minut do 7 dni. Ustawiając tę wartość, pamiętaj o tych kompromisach:- Bezpieczeństwo: krótsze TTL zapewniają większe bezpieczeństwo, ponieważ zmniejszają okno, w którym wyciekły 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 atestacji aplikacji dodaje opóźnienie do żądań sieciowych za każdym razem, gdy jest wykonywany, krótki TTL może wpłynąć na wydajność aplikacji.
Domyślny TTL wynoszący 1 godzinę jest odpowiedni dla większości aplikacji.
Dalsze kroki
Teraz, gdy masz już wdrożoną logikę po stronie serwera niestandardowego dostawcy, dowiedz się, jak używać jej w klientach Apple, Android i internetowych.