Implementa un proveedor personalizado de la Verificación de aplicaciones
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
App Check tiene compatibilidad integrada con varios proveedores: DeviceCheck y App
Attest en plataformas de Apple, Play Integrity 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 App Check. 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 App Check para SO de computadoras o
dispositivos del 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 App Check, necesitas un entorno de backend seguro que pueda ejecutar Firebase Admin SDK de Node.js.
Puede ser Cloud Functions, una plataforma de contenedores 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 App Check. 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
Instala e inicializa Admin SDK.
Crea un extremo al que se pueda acceder desde la red y que pueda recibir datos de autenticidad de tus clientes. Por ejemplo, con Cloud Functions:
// 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 App Check, que deberás escribir tú mismo.
Si determinas que el cliente es auténtico, usa Admin SDK para crear un token de App Check y mostrarlo 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 AppCheckTokenOptions a createToken() a fin de configurar un tiempo de actividad (TTL) para los tokens de App Check 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.
Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de Creative Commons, y los ejemplos de código están sujetos a la licencia Apache 2.0. Para obtener más información, consulta las políticas del sitio de Google Developers. Java es una marca registrada de Oracle o sus afiliados.
Última actualización: 2025-08-23 (UTC)
[null,null,["Última actualización: 2025-08-23 (UTC)"],[],[],null,["App Check has built-in support for several providers: DeviceCheck and App\nAttest on Apple platforms, Play Integrity on Android, and reCAPTCHA Enterprise\nin web apps ([overview](/docs/app-check)). These are well-understood providers\nthat should meet the needs of most developers. You can, however, also implement\nyour own custom App Check providers. Using a custom provider is necessary\nwhen:\n\n- You want to use a provider other than the built-in ones.\n\n- You want to use the built-in providers in unsupported ways.\n\n- You want to verify devices using platforms other than Apple, Android, and the\n web. For example, you could create App Check providers for desktop OSes or\n Internet-of-Things devices.\n\n- You want to implement your own verification techniques on any platform.\n\nOverview\n\nTo implement a custom App Check provider, you need a secure backend\nenvironment that can run the Node.js [Firebase Admin SDK](/docs/admin/setup).\nThis can be Cloud Functions, a container platform such as\n[Cloud Run](https://cloud.google.com/run), or your own server.\n\nFrom this environment, you will provide a network-accessible service that\nreceives proof of authenticity from your app clients, and---if the proof of\nauthenticity passes your authenticity assessment---returns an App Check\ntoken. The specific indicators you use as proof of authenticity will depend on\neither the third-party provider you're using, or the indicators of your own\ninvention, if you're implementing custom logic.\n\nUsually, you expose this service as a REST or gRPC endpoint, but this detail is\nup to you.\n\nCreate the token acquisition endpoint\n\n1. [Install and initialize the Admin SDK](/docs/admin/setup).\n\n2. Create a network-accessible endpoint that can receive authenticity data from\n your clients. For example, using Cloud Functions:\n\n // Create endpoint at https://example-app.cloudfunctions.net/fetchAppCheckToken\n exports.fetchAppCheckToken = functions.https.onRequest((request, response) =\u003e {\n // ...\n });\n\n3. Add to the endpoint logic that assesses the authenticity data. This is the\n core logic of your custom App Check provider, which you will need to\n write yourself.\n\n4. If you determine the client to be authentic, use the Admin SDK to mint\n an App Check token and return it and its expiration time to the client:\n\n const admin = require('firebase-admin');\n admin.initializeApp();\n\n // ...\n\n admin.appCheck().createToken(appId)\n .then(function (appCheckToken) {\n // Token expires in an hour.\n const expiresAt = Math.floor(Date.now() / 1000) + 60 * 60;\n\n // Return appCheckToken and expiresAt to the client.\n })\n .catch(function (err) {\n console.error('Unable to create App Check token.');\n console.error(err);\n });\n\n | **Note:** If you encounter a token signing error while creating a new token, make sure your service account has the required permissions. See the [Admin SDK troubleshooting guide](/docs/auth/admin/create-custom-tokens#troubleshooting).\n\n If you can't verify the client's authenticity, return an error (for example,\n return an HTTP 403 error).\n5. **Optional** : Set the time-to-live (TTL) for App Check tokens issued by\n your custom provider by passing an `AppCheckTokenOptions` object to\n `createToken()`. You can set the TTL to any value between 30 minutes and 7\n days. When setting this value, be aware of the following tradeoffs:\n\n - Security: Shorter TTLs provide stronger security, because it reduces the window in which a leaked or intercepted token can be abused by an attacker.\n - Performance: Shorter TTLs mean your app will perform attestation more frequently. Because the app attestation process adds latency to network requests every time it's performed, a short TTL can impact the performance of your app.\n\n The default TTL of 1 hour is reasonable for most apps.\n\nNext steps\n\nNow that you've implemented your custom provider's server-side logic, learn how\nto use it from your [Apple](/docs/app-check/ios/custom-provider),\n[Android](/docs/app-check/android/custom-provider), and [web](/docs/app-check/web/custom-provider) clients."]]
