Què és un entitlement i per què s'ha de gestionar al servidor i no al mòbil

En el desenvolupament de programari i serveis mòbils, vendre accés digital sovint es confon amb concedir-lo. Un usuari completa un flux de pagament a l'App Store, a Google Play o al web, el dispositiu rep una confirmació i, immediatament, la pantalla desbloqueja la funció de pagament. Tanmateix, vincular directament el rebut de compra amb la interfície del telèfon és una font constant d'errors operatius i d'escletxes de seguretat. Per resoldre aquest desacoblament existeix el concepte d'entitlement.

Comprendre què representa i per què s'ha de calcular i persistir als teus propis servidors resulta fonamental per a qualsevol empresa que operi amb pagos en apps i busqui un model de negoci recurrent i consistent.

Què és exactament un entitlement

Un entitlement (o dret d'accés) és la representació lògica del permís que té un usuari específic per gaudir d'una característica, contingut o nivell de servei dins d'una plataforma durant un període determinat.

Convé no confondre'l amb el producte comercial ni amb la transacció econòmica:

• Producte o SKU: És l'element que es publica a les botigues d'aplicacions o al catàleg del checkout (per exemple, `suscripcion_anual_pro`).
• Transacció o rebut: És el comprovant signat criptogràficament per la botiga o per la passarel·la de pagament que certifica que s'ha processat un cobrament amb èxit o que s'ha emès un període de prova.
• Entitlement: És la conclusió operativa que extreu el teu sistema a partir d'aquestes transaccions. Per exemple, l'etiqueta interna `acceso_modulo_analitica` amb data de caducitat fixada a les 23:59 del 15 d'octubre.

Un únic producte comercial pot atorgar múltiples entitlements independents, i diversos productes diferents (un pla mensual contractat a iOS i un pla corporatiu facturat per transferència bancària) poden concedir exactament el mateix entitlement.

Els riscos de resoldre els permisos al dispositiu

Durant anys, moltes aplicacions mòbils van implementar la validació de compres al mateix client: l'app rebia el rebut criptogràfic de la botiga, el verificava localment mitjançant biblioteques del sistema operatiu i desava una bandera booleana (com ara `isPro = true`) a l'emmagatzematge del dispositiu.

Aquest patró comporta vulnerabilitats tècniques i de negoci evidents:

• Manipulació de l'entorn d'execució: En dispositius arrelats o amb jailbreak, interceptar i modificar respostes binàries o variables en memòria és trivial amb eines d'anàlisi dinàmica. Si la decisió de concedir accés depèn d'una variable local, l'aplicació pot ser desbloquejada sense haver pagat mai.
• Atacs de repetició (receipt replay): Un rebut vàlid emès per a un compte pot interceptar-se i reenviar-se a l'app d'un altre usuari. Si el client no valida de manera estricta contra un servidor que vinculi aquest identificador de transacció únic a un usuari autenticat concret, el mateix rebut desbloqueja el servei a desenes de persones.
• Inconsistència multiplataforma: Si el permís viu al mòbil, un usuari que paga la seva subscripció en un iPhone no pot gaudir de les funcions quan inicia sessió a la web o en una tauleta Android, obligant a duplicar compres o generant fricció al servei d'atenció al client.

Arquitectura desacoblada: el servidor com a àrbitre de la veritat

Per blindar el model de negoci, el client mòbil no ha de decidir mai quines funcions estan disponibles. La seva funció s'ha de limitar a presentar la interfície de pagament, transferir el rebut obtingut al backend del negoci i consultar a aquest darrer quins drets té actius l'usuari autenticat.

El flux tècnic segur segueix aquest ordre:

1. L'usuari completa el procés de compra dins de l'app mòbil.

2. L'aplicació rep el token o rebut signat de la botiga (App Store o Google Play) i el transmet mitjançant una connexió xifrada a l'API del teu servidor.

3. El teu backend contacta directament amb les API oficials de validació de la botiga corresponent per comprovar l'autenticitat del rebut, la seva vigència i que l'identificador de transacció no hagi estat registrat prèviament per un altre compte.

4. Si la comprovació és positiva, el servidor crea o actualitza el registre de l'entitlement a la seva pròpia base de dades, associant-lo a l'identificador únic d'usuari de la teva plataforma.

5. El servidor retorna a l'app la llista consolidada de permisos vigents.

Sota aquest esquema, qualsevol petició que accedeixi a recursos protegits o a la sincronització de dades ha de validar l'entitlement directament al backend abans de retornar la informació sensible.

Gestió del cicle de vida i esdeveniments asíncrons

Les subscripcions modernes no són estàtiques. Al llarg del temps travessen renovacions, períodes de gràcia per targeta rebutjada, pauses temporals, cancel·lacions i reemborsaments.

Si la lògica descansa al dispositiu, aquest hauria de consultar periòdicament les botigues per saber si la targeta continua passant o si l'usuari ha sol·licitat una devolució a través del suport d'Apple o Google. Aquest enfocament genera retards i un consum innecessari de bateria i dades.

En centralitzar els drets al servidor, les plataformes de distribució i els processadors de pagament notifiquen els canvis en temps real mitjançant notificacions servidor a servidor o webhooks firmados y datos de tarjeta que no debes guardar. Quan un cobrament falla, entra en joc l'operativa de renovación automática de suscripciones; el teu backend pot decidir immediatament si manté actiu l'entitlement durant uns dies de cortesia o si degrada el compte al pla bàsic sense que l'app requereixi cap actualització a les botigues.

Conclusió pràctica

Tractar la compra com un succés transaccional i l'entitlement com l'estat resultant d'un dret d'accés és l'única estratègia viable per construir aplicacions sostenibles i escalables. Mantenir aquesta lògica al backend protegeix la rendibilitat davant del frau habitual en clients mòbils, unifica l'experiència dels teus clients sense importar el canal on hagin pagat i permet reaccionar a devolucions i cancel·lacions de manera immediata i precisa.