Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Implementar un proveedor de verificación de aplicaciones personalizado

App Check ha incorporado soporte para varios proveedores: DeviceCheck en IOS, SafetyNet en Android, o v3 reCAPTCHA 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 de App Check personalizados. Es necesario utilizar un proveedor personalizado cuando:

  • Desea utilizar un proveedor que no sea DeviceCheck en iOS, SafetyNet en Android o reCAPTCHA en aplicaciones web.

  • Desea verificar los dispositivos que utilizan plataformas distintas de iOS, Android y la web. Por ejemplo, puede 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.

Descripción general

Para implementar un proveedor Comprobar aplicación personalizada, necesita un entorno seguro back-end que pueda ejecutar el Node.js Firebase SDK del administrador . Esto puede ser Funciones nube, una plataforma de contenedor, como la nube de ejecución , o en 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é utilizando o de los indicadores de su propia invención, si está implementando una lógica personalizada.

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

Crear el punto final de adquisición de tokens

  1. Instalar e inicializar el SDK de administración .

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

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

  4. Si determina que el cliente es auténtico, utilice el SDK de administrador para crear un token de verificación de aplicaciones y devuélvalo y su fecha de vencimiento 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: Establecer el tiempo de vida (TTL) para la aplicación Verificar fichas emitidas por el proveedor personalizado haciendo pasar una AppCheckTokenOptions opone 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 compensaciones:

    • Seguridad: los TTL más cortos brindan mayor seguridad, ya que reducen la ventana en la que un atacante puede abusar de un token filtrado o interceptado.
    • Rendimiento: TTL más cortos significa que su aplicación realizará la certificación con más frecuencia. Debido a que el proceso de certificación de la aplicación agrega latencia a las solicitudes de red cada vez que se realiza, un TTL corto 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, aprender a usarlo desde sus iOS , Android y web clientes.