Join us in person and online for Firebase Summit on October 18, 2022. Learn how Firebase can help you accelerate app development, release your app with confidence, and scale with ease. Register now

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 nas 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 compreendidos que devem atender às necessidades da maioria dos desenvolvedores. No entanto, você também pode implementar seus próprios provedores personalizados do App Check. O uso de um provedor personalizado é necessário quando:

  • Você deseja usar um provedor diferente dos internos.

  • 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 SDK Admin do Firebase Node.js . 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 a prova de autenticidade de seus clientes de aplicativo 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 de terceiros 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 fica a seu critério.

Crie o endpoint de aquisição de token

  1. Instale e inicialize o SDK Admin .

  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 endpoint que avalia os dados de autenticidade. Essa é a lógica central do seu provedor de verificação de aplicativo personalizado, que você mesmo precisará escrever.

  4. Se você determinar que o cliente é autêntico, use o SDK Admin para cunhar um token do App Check e devolvê-lo e 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 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 realizará o atestado 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, saiba como usá-la em seus clientes Apple , Android e Web .