Entitlements en aplicacións móbiles: por que delegar a autorización no servidor evita fendas de acceso

No desenvolvemento de software móbil adóitase cometer un erro frecuente: equiparar a compra dun produto coa concesión directa de acceso dentro do dispositivo. Cando un usuario completa un pagamento en App Store ou Google Play, a aplicación recibe unha confirmación local. Porén, confiar en que o propio teléfono interprete ese sinal e desbloquee funcións prémium crea unha arquitectura vulnerable e difícil de manter.

Para resolver este desacoplamento técnico utilízase o concepto de entitlement (ou dereito de acceso), unha capa de abstracción que define que funcións, contidos ou niveis de servizo corresponden a un usuario nun momento determinado, con independencia de como ou onde se pagasen.

Que diferenza un produto dun entitlement

Un produto ou SKU representa un elemento comercial concreto no catálogo dunha tenda: unha subscrición mensual estándar, un plan anual rebaixado ou un paquete de créditos. Cada plataforma móbil esixe configurar identificadores independentes para estes cobros.

En cambio, un entitlement representa o permiso funcional na aplicación. Por exemplo, un usuario pode dispoñer do dereito `acceso_pro`. A ese mesmo dereito pódese chegar mediante múltiples vías:

• Unha subscrición mensual contratada desde iOS dentro do marco de pagos en apps.
• Un plan anual adquirido en Android cunha promoción temporal.
• Un pagamento corporativo con tarxeta procesado na web a través dunha pasarela tradicional.
• Unha asignación manual realizada polo equipo de soporte técnico.

Se a lóxica da aplicación comproba directamente identificadores de produto locais como `com.empresa.app.mensual_ios`, calquera cambio de catálogo obriga a actualizar o código da app e publicar novas versións nas tendas. Abstraer esta lóxica cara a entitlements permite que a aplicación só pregunte se o usuario ten activo `acceso_pro`, delegando no backend a correspondencia entre pagamentos e dereitos.

Os riscos do control de permisos no móbil

Delegar a comprobación de dereitos no dispositivo cliente abre a porta a diversas fendas técnicas e de negocio en materia de seguridad:

• Manipulación binaria e inxección de código: En dispositivos con permisos de administrador alterados (jailbreak ou root), ferramentas dinámicas permiten interceptar respostas booleanas locais e forzar a aplicación a comportarse coma se existise unha compra válida.
• Ataques de repetición e recibos falsos: Se a aplicación le directamente o recibo de compra en local sen contrastalo coas interfaces de Apple ou Google mediante chaves privadas, un atacante pode reutilizar recibos lexítimos doutras contas ou xerar sinaturas simuladas.
• Falta de sincronización multiplataforma: Se o estado vive no móbil, un usuario que pague na súa tableta non disporá de acceso inmediato no seu teléfono nin no seu navegador web, xerando fricción e solicitudes innecesarias de soporte.

Centralizar o entitlement no servidor converte o cliente móbil nun mero terminal de presentación. A aplicación non decide se abre ou pecha unha pantalla; limítase a consultar o perfil do usuario autenticado contra a base de datos propia.

Validación servidor a servidor e eventos en tempo real

Para que un entitlement sexa fiable, o servidor debe recibir a confirmación da tenda a través dunha canle segura e contrastada. O fluxo técnico estándar opera nos seguintes pasos:

1. O dispositivo inicia e procesa a transacción na pasarela da tenda de aplicacións.

2. Ao recibir o identificador de transacción ou o token criptográfico asinado, o cliente non desbloquea o servizo, senón que o envía de inmediato á API do servidor propio.

3. O servidor comunícase coas API oficiais de Apple (StoreKit 2) ou Google (Google Play Developer API) para verificar a autenticidade do cobro e asociar o identificador orixinal de transacción ao identificador interno do usuario.

4. O servidor actualiza a táboa de entitlements na súa base de datos e devolve ao dispositivo móbil o novo estado consolidado.

Unha vez establecido o dereito inicial, o mantemento do ciclo de vida das suscripciones xestiónase mediante notificacións directas servidor a servidor (Server-to-Server Notifications ou RTDN). Cando un cobro recorrente falla, entra en período de graza ou é revogado, a tenda notifica directamente ao backend, o cal axusta ou cancela o entitlement en tempo real sen requirir que o usuario abra a aplicación.

Conclusión práctica

O terminal móbil é, por definición, unha contorna non confiable sobre a cal quen desenvolve carece de control absoluto. Manter a lóxica de autorización no dispositivo vinculada a produtos específicos complica o catálogo comercial e expón o negocio á fraude por manipulación local.

Establecer unha arquitectura onde as tendas comuniquen as transaccións a un servidor centralizado, e sexa este quen calcule e sirva os entitlements a cada cliente, reduce a dependencia de versións fixas da aplicación, facilita a unificación web e móbil, e garante que cada usuario acceda con exactitude ao servizo polo que pagou.