Реализация пользовательского поставщика проверки приложений.

App Check имеет встроенную поддержку нескольких провайдеров: 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.onRequest((request, response) => {
      // ...
    });
    
  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 по умолчанию, равное 1 часу, подходит для большинства приложений.

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

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

,

App Check имеет встроенную поддержку нескольких провайдеров: 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.onRequest((request, response) => {
      // ...
    });
    
  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 по умолчанию, равное 1 часу, подходит для большинства приложений.

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

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