En el desenvolupament d'aplicacions modernes, l'autenticació sol convertir-se en un laberint tècnic on conviuen tokens, cookies i fluxos de redirecció. Molts equips afronten aquest desafiament replicant receptes genèriques que, tot i que funcionen en entorns controlats, s'ensorraven davant d'amenaces reals. La clau no està en triar una única tecnologia —JWT, sessions o OAuth—, sinó a combinar-les com a capes d'un escut, similar a l'arquitectura de defensa en profunditat que utilitzen els sistemes crítics. En Q2BSTUDIO, on desenvolupem programari a mida per a empreses, entenem que cada aplicació requereix un model d' autenticació que equilibri seguretat, rendiment i experiència d' usuari.
El problema de les solucions monolítiques
Durant anys, l'enfocament habitual consistia a emmagatzemar un JWT en localStorage o sessionStorage, confiant que el frontend l'enviés en cada petició. No obstant això, qualsevol vulnerabilitat d'XSS permetia extreure aquest token i suplantar usuaris durant dies, ja que els tokens solien tenir una validesa excessiva. D'altra banda, les sessions clàssiques, tot i que segures davant XSS (en residir en cookies httpOnly), obligaven a mantenir estat en el servidor, complicant l'escalabilitat horitzontal. Aquí és on un enfocament per capes demostra el seu valor.
Les tres capes de l'autenticació moderna
La primera capa és l'access token, normalment un JWT de curta durada (5-15 minuts). Aquest token conté els claims necessaris perquè el backend validi la identitat sense consultar una base de dades. Com que és efímer, fins i tot si un atacant l'intercepta, el dany és mínim. L'ideal és mantenir-lo només en memòria del frontend (estat de React, variable JS) i mai en emmagatzematge persistent accessible per scripts.
La segona capa és el refresh token, un identificador opac que es guarda en una cookie amb les flagmes httpOnly, Secure i SameSite=Strict. Aquesta cookie només s'envia al servidor quan es necessita renovar l'access token. El refresh token ha de ser rotat: cada vegada que es fa servir, s' invalida l' antic i se n' emet un de nou. Si un atacant aconsegueix robar la cookie (una cosa difícil gràcies a httpOnly), la rotació ho detecta perquè el token ja haurà estat usat pel legítim.
La tercera capa és OAuth 2.0, que externalitza l'autenticació a proveïdors de confiança (Google, GitHub, Azure AD). OAuth no és un mecanisme de sessió, sinó un protocol de delegació. La implementació segura consisteix a realitzar el flux d'autorització en el backend, intercanviar el codi per tokens del proveïdor i després emetre els nostres propis access i refresh tokens. Així, el frontend mai maneja directament les credencials del proveïdor.
¿Sessions o JWT? No cal triar
Les sessions continuen sent útils en aplicacions server-side on es necessita estat persistent (per exemple, per a CSRF). No obstant això, en arquitectures de microserveis o APIs públiques, els JWT permeten validació stateless sense dependre d'un magatzem centralitzat. La combinació òptima fa servir sessions per a la UI tradicional (amb cookies) i JWT per a les anomenades API, recolzant-se en un backend que gestiona la renovació de tokens. En entorns cloud, amb serveis cloud AWS i Azure, aquesta arquitectura es desplega fàcilment usant sistemes com Redis per a la invalidació de refresh tokens.
Implementació pràctica
Un exemple amb Express mostra com construir aquest sistema. L'endpoint de login verifica credencials, genera un refresh token aleatori (jti) emmagatzemat a Redis amb TTL de 30 dies, l'envia com a cookie httpOnly, i retorna un access token JWT de 5 minuts. L'endpoint /token rep la cookie, verifica el jti a Redis, l'elimina (rotació), emet un nou refresh token i un nou access token. El logout simplement elimina el jti de Redis. Per protegir rutes, el middleware valida l'access token amb la clau pública corresponent.
Si s'integra OAuth, el flux canvia: el backend redirigeix l'usuari al proveïdor, rep el codi d'autorització, el bescanvia per un token d'accés del proveïdor, obté la identitat de l'usuari, i després emet els nostres propis tokens com es va descriure. D'aquesta manera, la capa OAuth només es fa servir per a l'autenticació inicial, mentre que la gestió de sessions continua sent responsabilitat de l'aplicació.
Gestió de riscos i ciberseguretat
Aquest model multicapa mitiga els atacs més comuns. L'XSS ja no pot robar refresh tokens (cookie httpOnly). El CSRF es preveu amb SameSite = Strict i, si cal, amb tokens anti-CSRF addicionals. La rotació de refresh tokens limita la finestra d'un possible robatori de cookie. A més, en usar secrets rotatius i emmagatzemar-los en variables d'entorn (no en el codi), es redueix l'impacte d'una filtració de repositori.
Per a empreses que necessiten protegir dades sensibles, Q2BSTUDIO ofereix serveis de ciberseguretat i pentesting que avaluen aquest tipus d'arquitectures, identificant possibles fuites de tokens o configuracions insegures a AWS o Azure. Així mateix, l'ús d'intel·ligència artificial per detectar patrons anòmals en l'ús de tokens (per exemple, múltiples renovacions en poc temps) pot reforçar la defensa.
Més enllà de l'autenticació: intel·ligència de negoci i automatització
Un cop la identitat està assegurada, les dades d'ús de l'autenticació (quan, on, com accedeixen els usuaris) es converteixen en una font valuosa per a la intel·ligència de negoci. Per exemple, mitjançant Power BI es poden visualitzar mètriques d' inicis de sessió, taxes de renovació de tokens o patrons d' accés geogràfic. Aquests dashboards permeten detectar comportaments sospitosos i optimitzar l'experiència de l'usuari. A més, els agents IA poden automatitzar respostes davant esdeveniments de seguretat, com revocar massivament tokens d'una sessió compromesa.
Conclusió
L'autenticació no ha de ser un monòlit, sinó una orquestració de mecanismes que es complementen. En combinar JWT per a accessos ràpids, refresh tokens en cookies segures i OAuth per a identitat federada, es construeix un sistema robust, escalable i mantenible. En aplicacions a mida desenvolupades per Q2BSTUDIO, apliquem aquesta filosofia des del disseny, adaptant-la a les necessitats de cada client, ja sigui al núvol amb serveis cloud AWS i Azure, en entorns de ciberseguretat, o integrant intel·ligència de negoci amb Power BI. Perquè cada capa compta, i només juntes construeixen la Matriu de seguretat que tota aplicació mereix.
