Внедрение пользовательского поставщика проверки приложений

Проверка приложений имеет встроенную поддержку нескольких поставщиков: DeviceCheck и App Attest на платформах Apple, Play Integrity и SafetyNet на Android и reCAPTCHA Enterprise в веб-приложениях ( обзор ). Это хорошо известные поставщики, которые должны удовлетворить потребности большинства разработчиков. Однако вы также можете реализовать свои собственные настраиваемые поставщики проверки приложений. Использование пользовательского поставщика необходимо, когда:

  • Вы хотите использовать провайдера, отличного от встроенного.

  • Вы хотите использовать встроенных поставщиков неподдерживаемыми способами.

  • Вы хотите проверить устройства, использующие платформы, отличные от Apple, Android и Интернета. Например, вы можете создать поставщиков проверки приложений для настольных ОС или устройств Интернета вещей.

  • Вы хотите реализовать свои собственные методы проверки на любой платформе.

Обзор

Чтобы внедрить настраиваемый поставщик проверки приложений, вам потребуется безопасная серверная среда, в которой можно запустить Node.js Firebase Admin SDK . Это могут быть Cloud Functions, контейнерная платформа, такая как Cloud Run , или ваш собственный сервер.

В этой среде вы предоставите доступную по сети службу, которая получает подтверждение подлинности от клиентов вашего приложения и, если доказательство подлинности проходит вашу оценку подлинности, возвращает токен проверки приложения. Конкретные индикаторы, которые вы используете в качестве доказательства подлинности, будут зависеть либо от используемого вами стороннего поставщика, либо от индикаторов вашего собственного изобретения, если вы реализуете пользовательскую логику.

Обычно вы предоставляете эту службу как конечную точку REST или gRPC, но эта деталь зависит от вас.

Создайте конечную точку получения токена

  1. Установите и инициализируйте Admin SDK .

  2. Создайте доступную по сети конечную точку, которая может получать данные о подлинности от ваших клиентов. Например, с помощью облачных функций:

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
    exports.fetchAppCheckToken = functions.https.onCall((authenticityData, context) => {
      // ...
    });
    
  3. Добавьте к логике конечной точки, которая оценивает данные подлинности. Это основная логика вашего собственного поставщика проверки приложений, который вам нужно будет написать самостоятельно.

  4. Если вы определили, что клиент является подлинным, используйте Admin SDK, чтобы создать токен проверки приложения и вернуть его вместе со сроком действия клиенту:

    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);
       });
    

    Если вы не можете проверить подлинность клиента, верните ошибку (например, верните ошибку HTTP 403).

  5. Необязательно : установите время жизни (TTL) для токенов проверки приложений, выпущенных вашим настраиваемым поставщиком, передав объект AppCheckTokenOptions в createToken() . Вы можете установить TTL на любое значение от 30 минут до 7 дней. При установке этого значения имейте в виду следующие компромиссы:

    • Безопасность: более короткие значения TTL обеспечивают более высокий уровень безопасности, поскольку они уменьшают окно, в котором злоумышленник может злоупотребить утечкой или перехваченным токеном.
    • Производительность. Более короткие TTL означают, что ваше приложение будет выполнять аттестацию чаще. Поскольку процесс аттестации приложения добавляет задержку к сетевым запросам каждый раз, когда он выполняется, короткий TTL может повлиять на производительность вашего приложения.

    Значение TTL по умолчанию, равное 1 часу, подходит для большинства приложений.

Следующие шаги

Теперь, когда вы реализовали серверную логику своего пользовательского поставщика, узнайте, как использовать ее в своих клиентах Apple , Android и веб- клиентах.