Que é un entitlement e por que debe xestionarse no servidor e non no móbil

No desenvolvemento de software e servizos móbiles, vender acceso dixital adóitase confundir con concedelo. Un usuario completa un fluxo de pagamento na App Store, en Google Play ou na web, o dispositivo recibe unha confirmación e, de inmediato, a pantalla desbloquea a funcionalidade de pagamento. Porén, vincular directamente o recibo de compra coa interface do teléfono é unha fonte constante de erros operativos e de fendas de seguridade. Para resolver este desacoplamento existe o concepto de entitlement.

Comprender que representa e por que debe calcularse e persistir nos teus propios servidores resulta fundamental para calquera empresa que opere con pagos en apps e procure un modelo de negocio recorrente e consistente.

Que é exactamente un entitlement

Un entitlement (ou dereito de acceso) é a representación lóxica do permiso que ten un usuario específico para gozar dunha característica, contido ou nivel de servizo dentro dunha plataforma durante un período determinado.

Convén non confundilo co produto comercial nin coa transacción económica:

• Produto ou SKU: É o elemento que se publica nas tendas de aplicacións ou no catálogo do checkout (por exemplo, `suscripcion_anual_pro`).
• Transacción ou recibo: É o comprobante asinado criptograficamente pola tenda ou pola pasarela de pagamento que certifica que se procesou un cobro con éxito ou que se concedeu un período de proba.
• Entitlement: É a conclusión operativa que extrae o teu sistema a partir desas transaccións. Por exemplo, a etiqueta interna `acceso_modulo_analitica` con data de caducidade fixada ás 23:59 do 15 de outubro.

Un único produto comercial pode outorgar múltiples entitlements independentes, e varios produtos distintos (un plan mensual contratado en iOS e un plan corporativo facturado por transferencia bancaria) poden conceder exactamente o mesmo entitlement.

Os riscos de resolver os permisos no dispositivo

Durante anos, moitas aplicacións móbiles implementaron a validación de compras no propio cliente: a app recibía o recibo criptográfico da tenda, verificábao localmente mediante bibliotecas do sistema operativo e gardaba unha bandeira booleana (coma `isPro = true`) no almacenamento do dispositivo.

Este patrón conleva vulnerabilidades técnicas e de negocio evidentes:

• Manipulación do contorno de execución: En dispositivos con acceso root ou jailbreak, interceptar e modificar respostas binarias ou variables en memoria é sinxelo con ferramentas de análise dinámica. Se a decisión de conceder acceso depende dunha variable local, a aplicación pódese desbloquear sen ter pagado xamais.
• Ataques de repetición (receipt replay): Un recibo válido emitido para unha conta pódese interceptar e reenviar á app doutro usuario. Se o cliente non valida de forma estrita contra un servidor que vincule ese identificador de transacción único a un usuario autenticado concreto, o mesmo recibo desbloquea o servizo a ducias de persoas.
• Inconsistencia multiplataforma: Se o permiso reside no móbil, un usuario que paga a súa subscrición nun iPhone non pode gozar das funcións cando inicia sesión na web ou nunha tableta Android, o que obriga a duplicar compras ou xera fricción no soporte técnico.

Arquitectura desacoplada: o servidor como árbitro da verdade

Para blindar o modelo de negocio, o cliente móbil nunca debe decidir que funcións están dispoñibles. A súa función debe limitarse a presentar a interface de pagamento, transferir o recibo obtido ao backend do negocio e consultar a este último que dereitos ten activos o usuario autenticado.

O fluxo técnico seguro segue esta orde:

1. O usuario completa o proceso de compra dentro da app móbil.

2. A aplicación recibe o token ou recibo asinado da tenda (App Store ou Google Play) e transmíteo mediante unha conexión cifrada á API do teu servidor.

3. O teu backend contacta directamente coas API oficiais de validación da tenda correspondente para comprobar a autenticidade do recibo, a súa vixencia e que o identificador de transacción non fose rexistrado previamente por outra conta.

4. Se a comprobación é positiva, o servidor crea ou actualiza o rexistro do entitlement na súa propia base de datos, asociándoo ao identificador único de usuario da túa plataforma.

5. O servidor devolve á app a lista consolidada de permisos vixentes.

Baixo este esquema, calquera petición que acceda a recursos protexidos ou á sincronización de datos debe validar o entitlement directamente no backend antes de devolver a información confidencial.

Xestión do ciclo de vida e eventos asíncronos

As subscricións actuais non son estáticas. Ao longo do tempo atravesan renovacións, períodos de graza por tarxeta rexeitada, pausas temporais, cancelacións e reembolsos.

Se a lóxica descansa no dispositivo, este tería que consultar periodicamente ás tendas para saber se a tarxeta segue pasando ou se o usuario solicitou unha devolución a través do servizo de atención de Apple ou Google. Este enfoque xera atrasos e un consumo innecesario de batería e datos.

Ao centralizar os dereitos no servidor, as plataformas de distribución e os procesadores de pagamento notifican os cambios en tempo real mediante notificacións servidor a servidor ou webhooks firmados y datos de tarjeta que no debes guardar. Cando un cobro falla, entra en xogo a operativa de renovación automática de suscripciones; o teu backend pode decidir de inmediato se mantén activo o entitlement durante uns días de cortesía ou se degrada a conta ao plan básico sen que a app requira ningunha actualización nas tendas.

Conclusión práctica

Tratar a compra como un suceso transaccional e o entitlement como o estado resultante dun dereito de acceso é a única estratexia viable para construír aplicacións sustentables e escalables. Manter esa lóxica no backend protexe os ingresos fronte á fraude habitual en clientes móbiles, unifica a experiencia dos teus clientes sen importar a canle onde pagasen e permite reaccionar a devolucións e cancelacións dun xeito inmediato e rigoroso.