Entitlements en aplicaciones móviles: por qué delegar la autorización en el servidor evita brechas de acceso

En el desarrollo de software móvil suele cometerse un error frecuente: equiparar la compra de un producto con la concesión directa de acceso dentro del dispositivo. Cuando un usuario completa un pago en App Store o Google Play, la aplicación recibe una confirmación local. Sin embargo, confiar en que el propio teléfono interprete esa señal y desbloquee funciones prémium crea una arquitectura vulnerable y difícil de mantener.

Para resolver este desacoplamiento técnico se utiliza el concepto de entitlement (o derecho de acceso), una capa de abstracción que define qué funciones, contenidos o niveles de servicio corresponden a un usuario en un momento determinado, con independencia de cómo o dónde se hayan pagado.

Qué diferencia a un producto de un entitlement

Un producto o SKU representa un elemento comercial concreto en el catálogo de una tienda: una suscripción mensual estándar, un plan anual rebajado o un paquete de créditos. Cada plataforma móvil exige configurar identificadores independientes para estos cobros.

En cambio, un entitlement representa el permiso funcional en la aplicación. Por ejemplo, un usuario puede disponer del derecho `acceso_pro`. A ese mismo derecho se puede llegar mediante múltiples vías:

• Una suscripción mensual contratada desde iOS dentro del marco de pagos en apps.
• Un plan anual adquirido en Android con una promoción temporal.
• Un pago corporativo con tarjeta procesado en la web a través de una pasarela tradicional.
• Una asignación manual realizada por el equipo de soporte técnico.

Si la lógica de la aplicación comprueba directamente identificadores de producto locales como `com.empresa.app.mensual_ios`, cualquier cambio de catálogo obliga a actualizar el código de la app y desplegar nuevas versiones en las tiendas. Abstraer esta lógica hacia entitlements permite que la aplicación solo pregunte si el usuario tiene activo `acceso_pro`, delegando en el backend la correspondencia entre pagos y derechos.

Los riesgos del control de permisos en el móvil

Delegar la comprobación de derechos en el dispositivo cliente abre la puerta a diversas brechas técnicas y de negocio en materia de seguridad:

• Manipulación binaria e inyección de código: En dispositivos con permisos de administrador alterados (jailbreak o root), herramientas dinámicas permiten interceptar respuestas booleanas locales y forzar a la aplicación a comportarse como si existiera una compra válida.
• Ataques de repetición y recibos falsos: Si la aplicación lee directamente el recibo de compra en local sin contrastarlo con las interfaces de Apple o Google mediante claves privadas, un atacante puede reutilizar recibos legítimos de otras cuentas o generar firmas simuladas.
• Falta de sincronización multiplataforma: Si el estado vive en el móvil, un usuario que pague en su tableta no dispondrá de acceso inmediato en su teléfono ni en su navegador web, generando fricción y solicitudes innecesarias de soporte.

Centralizar el entitlement en el servidor convierte al cliente móvil en un mero terminal de presentación. La aplicación no decide si abre o cierra una pantalla; se limita a consultar el perfil del usuario autenticado contra la base de datos propia.

Validación servidor a servidor y eventos en tiempo real

Para que un entitlement sea fiable, el servidor debe recibir la confirmación de la tienda a través de un canal seguro y contrastado. El flujo técnico estándar opera en los siguientes pasos:

1. El dispositivo inicia y procesa la transacción en la pasarela de la tienda de aplicaciones.

2. Al recibir el identificador de transacción o el token criptográfico firmado, el cliente no desbloquea el servicio, sino que lo envía de inmediato a la API del servidor propio.

3. El servidor se comunica con las APIs oficiales de Apple (StoreKit 2) o Google (Google Play Developer API) para verificar la autenticidad del cobro y asociar el identificador original de transacción al identificador interno del usuario.

4. El servidor actualiza la tabla de entitlements en su base de datos y devuelve al dispositivo móvil el nuevo estado consolidado.

Una vez establecido el derecho inicial, el mantenimiento del ciclo de vida de las suscripciones se gestiona mediante notificaciones directas servidor a servidor (Server-to-Server Notifications o RTDN). Cuando un cobro recurrente falla, entra en periodo de gracia o es revocado, la tienda notifica directamente al backend, el cual ajusta o cancela el entitlement en tiempo real sin requerir que el usuario abra la aplicación.

Conclusión práctica

El terminal móvil es, por definición, un entorno no confiable sobre el que el desarrollador carece de control absoluto. Mantener la lógica de autorización en el dispositivo vinculada a productos específicos complica el catálogo comercial y expone el negocio al fraude por manipulación local.

Establecer una arquitectura donde las tiendas comuniquen las transacciones a un servidor centralizado, y sea este quien calcule y sirva los entitlements a cada cliente, reduce la dependencia de versiones fijas de la app, facilita la unificación web y móvil, y garantiza que cada usuario acceda con exactitud al servicio por el que ha pagado.