App Check ma wbudowane wsparcie dla kilku dostawców: DeviceCheck i AppAttest na platformach Apple, Play Integrity na Androidzie oraz reCAPTCHA Enterprise w aplikacjach internetowych (omówienie). Są to dobrze znani dostawcy, którzy powinni spełniać potrzeby większości deweloperów. Możesz też zaimplementować własne niestandardowe dostawców App Check. Używanie dostawcy niestandardowego jest konieczne, gdy:
Chcesz korzystać z usług 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 i internet. Możesz na przykład utworzyć dostawców App Check dla systemów operacyjnych na komputery lub urządzeń Internetu Rzeczy.
Chcesz wdrożyć własne techniki weryfikacji na dowolnej platformie.
Omówienie
Aby wdrożyć niestandardowy dostawca App Check, musisz mieć bezpieczne środowisko zaplecza, w którym można uruchomić Node.js Firebase Admin SDK. Może to być Cloud Functions, platforma kontenerowa, np. Cloud Run, lub własny serwer.
W tym środowisku udostępnisz usługę dostępną w sieci, która będzie otrzymywać od klientów aplikacji potwierdzenie autentyczności. Jeśli potwierdzenie autentyczności przejdzie Twoją ocenę autentyczności, zwróci token App Check. Konkretne wskaźniki, które użyjesz jako dowodu autentyczności, zależą od używanego dostawcy zewnętrznego lub wskaźników, które sam wymyślisz, jeśli wdrażasz logikę niestandardową.
Zwykle udostępniasz tę usługę jako punkt końcowy REST lub gRPC, ale to zależy od Ciebie.
Tworzenie punktu końcowego do pozyskiwania tokena
Utwórz punkt końcowy dostępny w sieci, który może otrzymywać dane dotyczące autentyczności od Twoich klientów. Na przykład: Cloud Functions:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken exports.fetchAppCheckToken = functions.https.onRequest((request, response) => { // ... });
Dodaj do logiki punktu końcowego funkcję, która ocenia dane dotyczące autentyczności. To jest główna logika niestandardowego dostawcy App Check, którą musisz napisać samodzielnie.
Jeśli uznasz, że klient jest autentyczny, użyj Admin SDK, aby wygenerować token App Check, a potem zgłoś go klientowi wraz z czasem jego ważności:
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, zwracaj błąd (np. błąd HTTP 403).
Opcjonalnie: ustaw czas życia (TTL) tokenów App Check wydanych przez niestandardowego dostawcę, przekazując obiekt
AppCheckTokenOptions
do funkcjicreateToken()
. Wartość TTL możesz ustawić na dowolną wartość od 30 minut do 7 dni. Podczas ustawiania tej wartości należy wziąć pod uwagę te kompromisy:- Bezpieczeństwo: krótsze czasy TTL zapewniają większą ochronę, ponieważ zmniejszają czas, w którym atakujący może wykorzystać wyciek lub przechwycenie tokena.
- Wydajność: krótsze czasy TTL oznaczają, że aplikacja będzie częściej przeprowadzać weryfikację. Ponieważ proces uwierzytelniania aplikacji zwiększa opóźnienie żądań sieciowych przy każdym jego wykonaniu, krótki czas trwania TTL może mieć wpływ na działanie aplikacji.
Domyślny okres ważności 1 godziny jest odpowiedni w przypadku większości aplikacji.
Dalsze kroki
Po zaimplementowaniu logiki po stronie serwera przez niestandardowego dostawcę dowiedz się, jak z niej korzystać w Apple, Androidzie i klientach internetowych.