Qué es un entitlement y por qué debe gestionarse en el servidor y no en el móvil

En el desarrollo de software y servicios móviles, vender acceso digital suele confundirse con concederlo. Un usuario completa un flujo de pago en App Store, Google Play o la web, el dispositivo recibe una confirmación y, de inmediato, la pantalla desbloquea la función de pago. Sin embargo, vincular directamente el recibo de compra con la interfaz del teléfono es una fuente constante de fallos operativos y brechas de seguridad. Para resolver este desacople existe el concepto de entitlement.

Comprender qué representa y por qué debe calcularse y persistir en tus propios servidores resulta fundamental para cualquier empresa que opere con pagos en apps y busque un modelo de negocio recurrente y consistente.

Qué es exactamente un entitlement

Un entitlement (o derecho de acceso) es la representación lógica del permiso que tiene un usuario específico para disfrutar de una característica, contenido o nivel de servicio dentro de una plataforma durante un periodo determinado.

Conviene no confundirlo con el producto comercial ni con la transacción económica:

• Producto o SKU: Es el elemento que se publica en las tiendas de aplicaciones o en el catálogo del checkout (por ejemplo, `suscripcion_anual_pro`).
• Transacción o recibo: Es el comprobante firmado criptográficamente por la tienda o por la pasarela que certifica que se ha procesado un cobro con éxito o que se ha emitido un periodo de prueba.
• Entitlement: Es la conclusión operativa que extrae tu sistema a partir de esas transacciones. Por ejemplo, la etiqueta interna `acceso_modulo_analitica` con fecha de caducidad fijada a las 23:59 del 15 de octubre.

Un único producto comercial puede otorgar múltiples entitlements independientes, y varios productos distintos (un plan mensual contratado en iOS y un plan corporativo facturado por transferencia bancaria) pueden conceder exactamente el mismo entitlement.

Los riesgos de resolver los permisos en el dispositivo

Durante años, muchas aplicaciones móviles implementaron la validación de compras en el propio cliente: la app recibía el recibo criptográfico de la tienda, lo verificaba localmente mediante bibliotecas del sistema operativo y guardaba una bandera booleana (como `isPro = true`) en el almacenamiento del dispositivo.

Este patrón acarrea vulnerabilidades técnicas y de negocio evidentes:

• Manipulación del entorno de ejecución: En dispositivos rooteados o con jailbreak, interceptar y modificar respuestas binarias o variables en memoria es trivial con herramientas de análisis dinámico. Si la decisión de conceder acceso depende de una variable local, la aplicación puede ser desbloqueada sin haber pagado jamás.
• Ataques de repetición (receipt replay): Un recibo válido emitido para una cuenta puede interceptarse y reenviarse a la app de otro usuario. Si el cliente no valida de forma estricta contra un servidor que vincule ese identificador de transacción único a un usuario autenticado concreto, el mismo recibo desbloquea el servicio a decenas de personas.
• Inconsistencia multiplataforma: Si el permiso vive en el móvil, un usuario que paga su suscripción en un iPhone no puede disfrutar de las funciones cuando inicia sesión en la web o en una tableta Android, obligando a duplicar compras o generando fricción en soporte.

Arquitectura desacoplada: el servidor como árbitro de la verdad

Para blindar el modelo de negocio, el cliente móvil nunca debe decidir qué funciones están disponibles. Su función debe limitarse a presentar la interfaz de pago, transferir el recibo obtenido al backend del negocio y consultar a este último qué derechos tiene activos el usuario autenticado.

El flujo técnico seguro sigue este orden:

1. El usuario completa el proceso de compra dentro de la app móvil.

2. La aplicación recibe el token o recibo firmado de la tienda (App Store o Google Play) y lo transmite mediante una conexión cifrada a la API de tu servidor.

3. Tu backend contacta directamente con las API oficiales de validación de la tienda correspondiente para comprobar la autenticidad del recibo, su vigencia y que el identificador de transacción no haya sido registrado previamente por otra cuenta.

4. Si la comprobación es positiva, el servidor crea o actualiza el registro del entitlement en su propia base de datos, asociándolo al identificador único de usuario de tu plataforma.

5. El servidor devuelve a la app la lista consolidada de permisos vigentes.

Bajo este esquema, cualquier petición que acceda a recursos protegidos o a la sincronización de datos debe validar el entitlement directamente en el backend antes de devolver la información sensible.

Gestión del ciclo de vida y eventos asíncronos

Las suscripciones modernas no son estáticas. A lo largo del tiempo atraviesan renovaciones, periodos de gracia por tarjeta rechazada, pausas temporales, cancelaciones y reembolsos.

Si la lógica descansa en el dispositivo, este tendría que consultar periódicamente a las tiendas para saber si la tarjeta sigue pasando o si el usuario ha solicitado una devolución a través del soporte de Apple o Google. Este enfoque genera retrasos y consumo innecesario de batería y datos.

Al centralizar los derechos en el servidor, las plataformas de distribución y los procesadores de pago notifican los cambios en tiempo real mediante notificaciones servidor a servidor o webhooks firmados y datos de tarjeta que no debes guardar. Cuando un cobro falla, entra en juego la operativa de renovación automática de suscripciones; tu backend puede decidir de inmediato si mantiene activo el entitlement durante unos días de cortesía o si degrada la cuenta al plan básico sin que la app requiera ninguna actualización en las tiendas.

Conclusión práctica

Tratar la compra como un suceso transaccional y el entitlement como el estado resultante de un derecho de acceso es la única estrategia viable para construir aplicaciones sostenibles y escalables. Mantener esa lógica en el backend protege la rentabilidad frente al fraude habitual en clientes móviles, unifica la experiencia de tus clientes sin importar el canal donde hayan pagado y permite reaccionar a devoluciones y cancelaciones de manera inmediata y precisa.