获取我们在 Firebase 峰会上发布的所有信息,了解 Firebase 可如何帮助您加快应用开发速度并满怀信心地运行应用。了解详情

Implementar un proveedor de verificación de aplicaciones personalizado

App Check tiene soporte integrado para varios proveedores: DeviceCheck y App Attest en plataformas Apple, Play Integrity y SafetyNet en Android, y reCAPTCHA v3 y reCAPTCHA Enterprise en aplicaciones web ( descripción general ). Estos son proveedores bien entendidos que deberían satisfacer las necesidades de la mayoría de los desarrolladores. Sin embargo, también puede implementar sus propios proveedores personalizados de App Check. El uso de un proveedor personalizado es necesario cuando:

  • Desea utilizar un proveedor que no sea el integrado.

  • Desea utilizar los proveedores integrados de formas no admitidas.

  • Desea verificar dispositivos que utilizan plataformas distintas de Apple, Android y la web. Por ejemplo, podría crear proveedores de App Check para sistemas operativos de escritorio o dispositivos de Internet de las cosas.

  • Quiere implementar sus propias técnicas de verificación en cualquier plataforma.

Visión general

Para implementar un proveedor personalizado de verificación de aplicaciones, necesita un entorno de back-end seguro que pueda ejecutar el SDK de administrador de Firebase de Node.js. Puede ser Cloud Functions, una plataforma de contenedores como Cloud Run o su propio servidor.

Desde este entorno, proporcionará un servicio accesible en red que recibe prueba de autenticidad de los clientes de su aplicación y, si la prueba de autenticidad pasa su evaluación de autenticidad, devuelve un token de verificación de aplicación. Los indicadores específicos que use como prueba de autenticidad dependerán del proveedor externo que esté usando o de los indicadores de su propia invención, si está implementando una lógica personalizada.

Por lo general, expone este servicio como un extremo REST o gRPC, pero este detalle depende de usted.

Crear el punto final de adquisición de tokens

  1. Instale e inicialice Admin SDK .

  2. Cree un punto final accesible a la red que pueda recibir datos de autenticidad de sus clientes. Por ejemplo, usando Cloud Functions:

    // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken
    exports.fetchAppCheckToken = functions.https.onCall((authenticityData, context) => {
      // ...
    });
    
  3. Agregue a la lógica del punto final que evalúa los datos de autenticidad. Esta es la lógica central de su proveedor personalizado de verificación de aplicaciones, que deberá escribir usted mismo.

  4. Si determina que el cliente es auténtico, use el SDK de administrador para crear un token de verificación de aplicaciones y devolverlo junto con su fecha de caducidad al 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);
       });
    

    Si no puede verificar la autenticidad del cliente, devuelva un error (por ejemplo, devuelva un error HTTP 403).

  5. Opcional : establezca el tiempo de vida (TTL) para los tokens de App Check emitidos por su proveedor personalizado pasando un objeto AppCheckTokenOptions a createToken() . Puede establecer el TTL en cualquier valor entre 30 minutos y 7 días. Al establecer este valor, tenga en cuenta las siguientes ventajas y desventajas:

    • Seguridad: los TTL más cortos brindan una mayor seguridad, ya que reducen la ventana en la que un atacante puede abusar de un token filtrado o interceptado.
    • Rendimiento: los TTL más cortos significan que su aplicación realizará la atestación con más frecuencia. Debido a que el proceso de atestación de la aplicación agrega latencia a las solicitudes de red cada vez que se realiza, un TTL breve puede afectar el rendimiento de su aplicación.

    El TTL predeterminado de 1 hora es razonable para la mayoría de las aplicaciones.

Próximos pasos

Ahora que ha implementado la lógica del lado del servidor de su proveedor personalizado, aprenda a usarla desde sus clientes Apple , Android y web .