Entitlements en aplicacions mòbils: per què delegar l'autorització al servidor evita bretxes d'accés

En el desenvolupament de programari mòbil se sol cometre un error freqüent: equiparar la compra d'un producte amb la concessió directa d'accés dins del dispositiu. Quan un usuari completa un pagament a l'App Store o a Google Play, l'aplicació rep una confirmació local. Tanmateix, confiar que el mateix telèfon interpreti aquest senyal i desbloquegi funcions prèmium crea una arquitectura vulnerable i difícil de mantenir.

Per resoldre aquest desacoblament tècnic s'utilitza el concepte d'entitlement (o dret d'accés), una capa d'abstracció que defineix quines funcions, continguts o nivells de servei corresponen a un usuari en un moment determinat, amb independència de com o on s'hagin pagat.

Què diferencia un producte d'un entitlement

Un producte o SKU representa un element comercial concret en el catàleg d'una botiga: una subscripció mensual estàndard, un pla anual rebaixat o un paquet de crèdits. Cada plataforma mòbil exigeix configurar identificadors independents per a aquests cobraments.

En canvi, un entitlement representa el permís funcional en l'aplicació. Per exemple, un usuari pot disposar del dret `acces_pro`. A aquest mateix dret s'hi pot arribar mitjançant múltiples vies:

• Una subscripció mensual contractada des d'iOS dins del marc de pagos en apps.
• Un pla anual adquirit a Android amb una promoció temporal.
• Un pagament corporatiu amb targeta processat a la web a través d'una passarel·la tradicional.
• Una assignació manual realitzada per l'equip de suport tècnic.

Si la lògica de l'aplicació comprova directament identificadors de producte locals com `com.empresa.app.mensual_ios`, qualsevol canvi de catàleg obliga a actualitzar el codi de l'aplicació i publicar noves versions a les botigues. Abstreure aquesta lògica cap a entitlements permet que l'aplicació només pregunti si l'usuari té actiu `acces_pro`, delegant en el backend la correspondència entre pagaments i drets.

Els riscos del control de permisos al mòbil

Delegar la comprovació de drets al dispositiu client obre la porta a diverses bretxes tècniques i de negoci en matèria de seguridad:

• Manipulació binària i injecció de codi: En dispositius amb permisos d'administrador alterats (jailbreak o root), eines dinàmiques permeten interceptar respostes booleanes locals i forçar l'aplicació a comportar-se com si existís una compra vàlida.
• Atacs de repetició i rebuts falsos: Si l'aplicació llegeix directament el rebut de compra en local sense contrastar-lo amb les interfícies d'Apple o Google mitjançant claus privades, un atacant pot reutilitzar rebuts legítims d'altres comptes o generar signatures simulades.
• Manca de sincronització multiplataforma: Si l'estat viu al mòbil, un usuari que pagui a la seva tauleta no disposarà d'accés immediat al seu telèfon ni al seu navegador web, fet que genera fricció i peticions innecessàries de suport.

Centralitzar l'entitlement al servidor converteix el client mòbil en un simple terminal de presentació. L'aplicació no decideix si obre o tanca una pantalla; es limita a consultar el perfil de l'usuari autenticat contra la base de dades pròpia.

Validació servidor a servidor i esdeveniments en temps real

Perquè un entitlement sigui fiable, el servidor ha de rebre la confirmació de la botiga a través d'un canal segur i contrastat. El flux tècnic estàndard opera en els passos següents:

1. El dispositiu inicia i processa la transacció a la passarel·la de la botiga d'aplicacions.

2. En rebre l'identificador de transacció o el token criptogràfic signat, el client no desbloqueja el servei, sinó que l'envia immediatament a l'API del servidor propi.

3. El servidor es comunica amb les API oficials d'Apple (StoreKit 2) o Google (Google Play Developer API) per verificar l'autenticitat del cobrament i associar l'identificador original de transacció a l'identificador intern de l'usuari.

4. El servidor actualitza la taula d'entitlements a la seva base de dades i retorna al dispositiu mòbil el nou estat consolidat.

Un cop establert el dret inicial, el manteniment del cicle de vida de les suscripciones es gestiona mitjançant notificacions directes servidor a servidor (Server-to-Server Notifications o RTDN). Quan un cobrament recurrent falla, entra en període de gràcia o és revocat, la botiga notifica directament el backend, el qual ajusta o cancel·la l'entitlement en temps real sense requerir que l'usuari obri l'aplicació.

Conclusió pràctica

El terminal mòbil és, per definició, un entorn no fiable sobre el qual el desenvolupador no té control absolut. Mantenir la lògica d'autorització al dispositiu vinculada a productes específics complica el catàleg comercial i exposa el negoci al frau per manipulació local.

Establir una arquitectura on les botigues comuniquin les transaccions a un servidor centralitzat, i sigui aquest qui calculi i serveixi els entitlements a cada client, redueix la dependència de versions fixes de l'aplicació, facilita la unificació web i mòbil, i garanteix que cada usuari accedeixi amb exactitud al servei pel qual ha pagat.