Catch up on everything announced at Firebase Summit, and learn how Firebase can help you accelerate app development and run your app with confidence. Learn More

Implementar um provedor personalizado do App Check

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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 v3 e reCAPTCHA Enterprise em aplicativos da web ( visão geral ). Esses são provedores bem conhecidos que devem atender às necessidades da maioria dos desenvolvedores. Você também pode, no entanto, implementar seus próprios provedores de App Check personalizados. O uso de 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 App Check personalizado, você precisa de um ambiente de back-end seguro que possa executar o Node.js Firebase Admin SDK . Pode ser o Cloud Functions, uma plataforma de contêiner como o Cloud Run ou seu próprio servidor.

A partir desse ambiente, você fornecerá um serviço acessível pela rede que recebe prova de autenticidade de seus clientes de aplicativos e, se a prova de autenticidade for aprovada em sua avaliação de autenticidade, retornará um token de verificação de aplicativo. Os indicadores específicos que você usa como prova de autenticidade dependerão do provedor terceirizado que você está usando ou dos indicadores de sua própria invenção, se estiver implementando uma lógica personalizada.

Normalmente, você expõe esse serviço como um endpoint REST ou gRPC, mas esse detalhe é com 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.onCall((authenticityData, context) => {
      // ...
    });
    
  3. Adicione à lógica do terminal que avalia os dados de autenticidade. Essa é a lógica principal do seu provedor de App Check personalizado, que você mesmo precisará escrever.

  4. Se você determinar que o cliente é autêntico, use o Admin SDK para criar um token do App Check e retorná-lo com seu tempo de expiração 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 você não puder 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 de App Check emitidos por 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, porque reduzem a janela na qual um token vazado ou interceptado pode ser abusado por um invasor.
    • Desempenho: TTLs mais curtos significam que seu aplicativo realizará 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 .