Wdrażanie niestandardowego dostawcy Sprawdzania aplikacji

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 za pomocą platform 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 zastosować 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 zewnętrznego dostawcy 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

  1. Zainstaluj i inicjuj Admin SDK.

  2. Utwórz punkt końcowy dostępny w sieci, który może odbierać dane dotyczące autentyczności od klientów. Na przykład: Cloud Functions:

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
    exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
      // ...
    });
    
  3. 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.

  4. Jeśli uznasz, że klient jest autentyczny, użyj Admin SDK, aby wygenerować token App Check, a następnie zwrócić 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).

  5. Opcjonalnie: ustaw czas życia danych (TTL) dla tokenów App Check wydanych przez niestandardowego dostawcę, przekazując obiekt AppCheckTokenOptions do funkcji createToken(). 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ę. Proces weryfikacji aplikacji wydłuża czas oczekiwania na żądania sieci za każdym razem, gdy jest wykonywany, dlatego 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, Androidzieklientach internetowych.