JWT: tokens firmados

Un JWT son tres trozos de texto separados por puntos. La cabecera es un JSON que indica el algoritmo de firma (alg) y el tipo; el contenido (payload) es otro JSON con los claims, las afirmaciones sobre el usuario; y la firma se calcula sobre los dos primeros trozos con una clave.

Cabecera y contenido van en Base64URL, una variante de Base64 que usa - y _ en lugar de + y / y quita el relleno =, para que el token viaje sin problemas en URLs y cabeceras. Pero Base64URL es una codificación, no un cifrado: cualquiera que tenga el token puede leer su contenido.

Firmado no es lo mismo que cifrado. La firma garantiza que nadie ha cambiado el contenido, pero no lo oculta. Existe una variante cifrada, JWE, aunque casi todos los JWT que verás son firmados (JWS).

El estándar reserva unos cuantos claims con significado fijo. iss (issuer) es quién emitió el token; sub (subject), a quién se refiere, normalmente el id del usuario; aud (audience), para qué API o app es. Los de tiempo van en segundos desde 1970 (tiempo Unix): exp es la caducidad, nbf (not before) el instante a partir del cual vale e iat (issued at) cuándo se emitió. jti es un identificador único del token.

A estos se suman los claims propios de cada aplicación, como rol o plan, y los estándar de OpenID Connect, como name o email.

Con HS256, la firma es un HMAC-SHA256 del texto cabecera.contenido calculado con un secreto. Para verificarla se repite el cálculo con el mismo secreto y se compara el resultado. Es rápido y sencillo.

El inconveniente es que quien puede verificar también puede firmar: si diez servicios validan tus tokens, los diez tienen el secreto, y cualquiera de ellos podría fabricar un token de administrador.

Con RS256 (RSA) o ES256 (curvas elípticas), el emisor firma con una clave privada que nunca sale de su servidor, y cualquiera puede verificar con la clave pública correspondiente. Tus APIs pueden validar tokens, pero ninguna puede fabricarlos.

Es lo que usan los proveedores de identidad como Google, Auth0 o Microsoft Entra ID. ES256 produce firmas y claves más pequeñas que RS256 con una seguridad comparable; RS256 sigue siendo el más extendido.

Un JWKS (JSON Web Key Set) es un documento que el emisor publica en una URL, la jwks_uri del descubrimiento de OpenID Connect, con sus claves públicas. Cada clave tiene un kid (key id), y cada token indica en su cabecera con qué kid se firmó.

Así se rotan las claves sin cortes: el emisor publica la clave nueva junto a la vieja, empieza a firmar con la nueva y retira la vieja cuando ya no quedan tokens firmados con ella.

Validar un token es una lista de comprobaciones, y fallar en una basta para rechazarlo: la firma es correcta con la clave esperada; el algoritmo está en tu lista de permitidos; iss es tu emisor; aud eres tú; y el instante actual está entre nbf y exp.

La lista de algoritmos permitidos es clave. El famoso ataque alg: none consiste en enviar un token con "alg": "none" y sin firma: algunas librerías antiguas leían el algoritmo de la propia cabecera y daban el token por bueno. Otra variante cambia RS256 por HS256 para que la librería use la clave pública como si fuera un secreto HMAC.

Si el servidor entrega el token en una cookie con los atributos HttpOnly, Secure y SameSite, el navegador lo guarda y lo adjunta solo a cada petición a ese dominio. Con HttpOnly, ningún script de la página puede leerlo, así que un ataque XSS (código malicioso inyectado en tu página) no puede robarlo y llevárselo.

Es la base del patrón BFF (Backend for Frontend): un pequeño backend propio guarda los tokens de OAuth y la SPA solo tiene una cookie de sesión con él.

Guardar el token con localStorage.setItem y añadirlo a mano en la cabecera Authorization es muy común en tutoriales porque es sencillo y no tiene problemas de CSRF: el navegador no lo envía solo.

El problema es que cualquier script que se ejecute en tu página puede leerlo: el tuyo, el de una librería comprometida o el de un ataque XSS. Un fetch al servidor del atacante basta para llevarse el token y usarlo desde otro lugar hasta que caduque.

Un access token que dura pocos minutos limita el daño si se roba, pero obligaría a iniciar sesión constantemente. La solución es un refresh token: una credencial de vida más larga que la app presenta en /token (grant_type=refresh_token) para obtener un access token nuevo sin molestar al usuario.

Con rotación, cada uso del refresh token devuelve uno nuevo e invalida el anterior. Si alguien intenta usar uno ya gastado, el servidor sabe que se ha robado y puede revocar toda la familia de tokens de esa sesión.

La ventaja de un JWT, que la API lo valida sin consultar a nadie, es también su punto débil: si despides a un empleado, su token sigue siendo válido hasta exp. Por eso la primera defensa es que los access tokens duren poco.

Para cortar el acceso al instante hay dos herramientas: revocar el refresh token en el servidor de autorización, para que no se emitan más access tokens, y, si hace falta, mantener una lista de revocados con los jti que la API consulta, que solo necesita guardarlos hasta su exp.