Implementar um provedor personalizado do App Check

O App Check tem suporte integrado para vários provedores: DeviceCheck e App Attest em plataformas Apple, Play Integrity e SafetyNet no Android e reCAPTCHA Enterprise em aplicativos da web ( visão geral ). Esses são fornecedores bem conhecidos que devem atender às necessidades da maioria dos desenvolvedores. No entanto, você também pode implementar seus próprios provedores personalizados do App Check. Usar um provedor personalizado é necessário quando:

  • Você deseja usar um provedor diferente dos integrados.

  • Você deseja usar os provedores integrados de maneiras não suportadas.

  • Você deseja verificar dispositivos usando plataformas diferentes da Apple, Android e da web. Por exemplo, você pode criar provedores de App Check para sistemas operacionais de desktop ou dispositivos de Internet das Coisas.

  • Você deseja implementar suas próprias técnicas de verificação em qualquer plataforma.

Visão geral

Para implementar um provedor personalizado do App Check, você precisa de um ambiente de back-end seguro que possa executar o Node.js Firebase Admin SDK . Pode ser Cloud Functions, uma plataforma de contêiner como Cloud Run ou seu próprio servidor.

Nesse ambiente, você fornecerá um serviço acessível pela rede que receberá prova de autenticidade dos clientes do seu aplicativo e, se a prova de autenticidade for aprovada na avaliação de autenticidade, retornará um token do App Check. Os indicadores específicos que você usa como prova de autenticidade dependerão do fornecedor terceirizado que você está usando ou dos indicadores de sua própria invenção, se você estiver implementando uma lógica personalizada.

Normalmente, você expõe esse serviço como um endpoint REST ou gRPC, mas esse detalhe depende de você.

Crie o endpoint de aquisição de token

  1. Instale e inicialize o Admin SDK .

  2. Crie um endpoint acessível pela rede que possa receber dados de autenticidade de seus clientes. Por exemplo, usando o Cloud Functions:

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
exports.fetchAppCheckToken = functions.https.onRequest((request, response) => {
  // ...
});

  3. Adicione à lógica do endpoint que avalia os dados de autenticidade. Esta é a lógica central do seu provedor personalizado do App Check, que você mesmo precisará escrever.

  4. Se você determinar que o cliente é autêntico, use o Admin SDK para gerar um token do App Check e devolvê-lo junto com seu prazo de validade ao cliente:

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

    Se não for possível verificar a autenticidade do cliente, retorne um erro (por exemplo, retorne um erro HTTP 403).

  5. Opcional : defina o tempo de vida (TTL) para tokens do App Check emitidos pelo seu provedor personalizado, passando um objeto AppCheckTokenOptions para createToken() . Você pode definir o TTL para qualquer valor entre 30 minutos e 7 dias. Ao definir esse valor, esteja ciente das seguintes compensações:

    • Segurança: TTLs mais curtos fornecem segurança mais forte, pois reduzem a janela na qual um token vazado ou interceptado pode ser abusado por um invasor.
    • Desempenho: TTLs mais curtos significam que seu aplicativo executará atestados com mais frequência. Como o processo de atestado do aplicativo adiciona latência às solicitações de rede sempre que é executado, um TTL curto pode afetar o desempenho do seu aplicativo.

    O TTL padrão de 1 hora é razoável para a maioria dos aplicativos.

Próximos passos

Agora que você implementou a lógica do lado do servidor do seu provedor personalizado, aprenda como usá-la em seus clientes Apple , Android e Web .