App Check tiene soporte integrado para varios proveedores: DeviceCheck y App Attest en plataformas Apple, Play Integrity y SafetyNet en Android y reCAPTCHA Enterprise en aplicaciones web ( descripción general ). Estos son proveedores bien conocidos 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 distinto de los integrados.
Quiere utilizar los proveedores integrados de formas no compatibles.
Quiere verificar dispositivos que utilizan plataformas distintas a 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.
Quieres implementar tus propias técnicas de verificación en cualquier plataforma.
Descripción general
Para implementar un proveedor de verificación de aplicaciones personalizado, necesita un entorno de backend seguro que pueda ejecutar el SDK de administración 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 utilice 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
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.onRequest((request, response) => { // ... });Agregue a la lógica del punto final que evalúa los datos de autenticidad. Esta es la lógica central de su proveedor de App Check personalizado, que deberá escribir usted mismo.
Si determina que el cliente es auténtico, use el SDK de administrador para generar un token de verificación de aplicación y devolverlo junto con su tiempo 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).
Opcional : establezca el tiempo de vida (TTL) para los tokens de verificación de aplicaciones emitidos por su proveedor personalizado pasando un objeto
AppCheckTokenOptionsacreateToken(). Puede configurar 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 proporcionan una mayor seguridad, porque 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 certificación con más frecuencia. Debido a que el proceso de certificación de aplicaciones 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, aprenda cómo usarla desde sus clientes web , Apple y Android .