Catch up on everthing we announced at this year's Firebase Summit. Learn more

Implementar um provedor de verificação de aplicativo personalizado

App check foi construído com suporte para vários provedores: DeviceCheck e App Attest em plataformas Apple, SafetyNet no Android, ou reCAPTCHA v3 em aplicações web ( visão geral ). Esses são provedores bem conhecidos que devem atender às necessidades da maioria dos desenvolvedores. No entanto, você também pode implementar seus próprios provedores de verificação de aplicativo personalizados. Usar um provedor personalizado é necessário quando:

  • Você deseja usar um provedor diferente de DeviceCheck ou App Attest na Apple, SafetyNet no Android ou reCAPTCHA em aplicativos da web.

  • Você deseja verificar dispositivos que usam plataformas diferentes da Apple, Android e da web. Por exemplo, você pode criar provedores de verificação de aplicativo 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 costume App check provedor, você precisa de um ambiente de backend seguro que pode executar o Node.js Firebase administração SDK . Isso pode ser Funções Nuvem, uma plataforma de recipiente, como Nuvem Run , ou o 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 passar em sua avaliação de autenticidade - retorna 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 ponto de extremidade REST ou gRPC, mas esse detalhe é com você.

Crie o endpoint de aquisição de token

  1. Instalar e inicializar o administrador SDK .

  2. Crie um ponto de extremidade acessível pela rede que pode receber dados de autenticidade de seus clientes. Por exemplo, usando 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. Esta é 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 de verificação de aplicativo e devolvê-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: Definir o time-to-live (TTL) para App Verifique fichas emitidas pelo seu provedor de costume pela passagem de um AppCheckTokenOptions opor-se createToken() . Você pode definir o TTL para qualquer valor entre 30 minutos e 7 dias. Ao definir esse valor, esteja ciente das seguintes desvantagens:

    • 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á 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 curto TTL 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ê já implementado lógica do lado do servidor do seu provedor personalizado, aprender a usá-lo de seus da Apple , Android e web clientes.