La Verificación de aplicaciones tiene compatibilidad integrada con varios proveedores: DeviceCheck y App Attest en plataformas de Apple, Play Integrity y SafetyNet en Android, y reCAPTCHA Enterprise en apps web (descripción general). Estos son proveedores bien comprendidos que deben satisfacer las necesidades de la mayoría de los desarrolladores. Sin embargo, también puedes implementar tus propios proveedores personalizados de la Verificación de aplicaciones. El uso de un proveedor personalizado es necesario en los siguientes casos:
Quieres usar un proveedor que no sea el integrado.
Deseas usar los proveedores integrados de formas no admitidas.
Si quieres verificar los dispositivos mediante plataformas que no sean Apple, Android ni la Web. Por ejemplo, podrías crear proveedores de la Verificación de aplicaciones para SO de computadoras o dispositivos de Internet de las cosas.
Si deseas implementar tus propias técnicas de verificación en cualquier plataforma.
Descripción general
Para implementar un proveedor personalizado de la Verificación de aplicaciones, necesitas un entorno de backend seguro que pueda ejecutar el SDK de Firebase Admin de Node.js. Puede ser Cloud Functions, una plataforma de contenedor como Cloud Run o tu propio servidor.
Desde este entorno, proporcionarás un servicio al que se pueda acceder desde la red que recibirá un comprobante de autenticidad de los clientes de la app y, si el comprobante aprueba tu evaluación de autenticidad, se mostrará un token de la Verificación de aplicaciones. Los indicadores específicos que uses como prueba de autenticidad dependerán del proveedor de terceros que uses o de los indicadores que creaste, si implementas una lógica personalizada.
Por lo general, expones este servicio como un extremo de REST o gRPC, pero este detalle depende de ti.
Crea el extremo de adquisición de tokens
Crea un extremo al que se pueda acceder desde la red y que pueda recibir datos de autenticidad de tus clientes. Por ejemplo, si usas Cloud Functions, haz lo siguiente:
// Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken exports.fetchAppCheckToken = functions.https.onRequest((request, response) => { // ... });Realiza un agregado a la lógica del extremo que evalúa los datos de autenticidad. Esta es la lógica central de tu proveedor personalizado de la Verificación de aplicaciones, que deberás escribir tú mismo.
Si determinas que el cliente es auténtico, usa el SDK de Admin para crear un token de la Verificación de aplicaciones y muéstraselo al cliente junto con su fecha y hora de vencimiento:
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 puedes verificar la autenticidad del cliente, muestra un error (por ejemplo, muestra un error HTTP 403).
Opcional: Pasa un objeto
AppCheckTokenOptionsacreateToken()a fin de configurar un tiempo de actividad (TTL) para los tokens de la Verificación de aplicaciones que emite tu proveedor personalizado. Puedes configurar el TTL en cualquier valor entre 30 minutos y 7 días. Cuando configures este valor, ten en cuenta las siguientes compensaciones:- Seguridad: Los TTL más cortos proporcionan una mayor seguridad, ya que reducen el período en el que un atacante puede abusar de un token filtrado o interceptado.
- Rendimiento: Si usas TTL más cortos, la app realizará la certificación con mayor frecuencia. Debido a que el proceso de certificación de la app agrega latencia a las solicitudes de red cada vez que se realiza, un TTL corto puede afectar el rendimiento de la app.
El TTL predeterminado de 1 hora es razonable para la mayoría de las apps.
Próximos pasos
Ahora que implementaste una lógica del servidor de tu proveedor personalizado, aprende a usarla en tus clientes de Apple, Android o la Web.