JWS

JWS (JSON Web Signature, RFC 7515) es el marco de firma criptográfica sobre el que se construye JWT. Un JWS tiene tres partes unidas por puntos: encabezado.contenido.firma, cada segmento codificado en base64url. El encabezado es JSON que declara el algoritmo; el contenido puede ser cualquier byte (típicamente pero no necesariamente JSON); la firma se calcula sobre el encabezado y el contenido unidos por puntos usando el algoritmo declarado.

La relación con JWT: todo JWT es un JWS cuyo contenido debe ser un objeto JSON de afirmaciones. Pero JWS en sí es más general — el contenido puede ser binario sin procesar, un documento XML o cualquier otra secuencia de bytes. Cuando ves un token de tres partes separadas por puntos cuya parte central no se decodifica en base64 como JSON, es un JWS, no un JWT.

Algoritmos comunes: HS256 (HMAC-SHA256, clave simétrica), RS256 (RSA-SHA256, asimétrico), ES256 (ECDSA-P256-SHA256, asimétrico). El peligroso algoritmo “none” significa “sin firma” — válido según la especificación pero siempre debe rechazarse en el lado del servidor. Los verificadores de producción también deben verificar explícitamente que el algoritmo declarado en el encabezado coincide con el algoritmo esperado para la clave.

JWS tiene dos serializaciones: compacta (el formato separado por puntos que usa JWT) y JSON (un sobre JSON que envuelve las mismas tres partes, compatible con múltiples firmas). La forma compacta es la que usa casi todas las API; la forma JSON es rara fuera de protocolos específicos.

Ejemplo práctico

Toma el JWS eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9.4Adcj3UFYzPUVaHwte4eBI6vsjOvpz0yiwIM0F7sjuk. Decodifica el encabezado (primer segmento): {"alg":"HS256"} — firma HMAC-SHA256. Decodifica el contenido (segundo segmento): {"sub":"user_123"}. La firma (tercer segmento) es HMAC-SHA256 de eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyXzEyMyJ9 usando la clave secreta compartida. El verificador reconstruye el HMAC y compara usando comparación en tiempo constante; si no coincide → rechazar. Ahora compara con RS256: misma estructura, pero la firma es RSA-SHA256, el emisor firma con una clave privada y los verificadores comprueban con la clave pública. Los bytes del token son más largos (las firmas RSA son ~342 caracteres base64 para una clave de 2048 bits vs 43 para HMAC-SHA256) pero la semántica de validación es idéntica desde la perspectiva del llamador.

Cuándo y por qué importa

JWS importa cada vez que un servicio emite, transmite o acepta un JWT — que en 2026 es la mayoría de las API. Los errores que han producido CVE repetidamente durante la última década: (1) no validar la firma en absoluto, tratando el contenido como confiable solo porque se analizó como JSON; (2) aceptar alg: none, que elimina la firma por completo; (3) aceptar cualquier algoritmo que declare el token, permitiendo el ataque de confusión HS256 con clave pública RSA; (4) no validar exp, permitiendo la reproducción de tokens largamente expirados; (5) no validar iss y aud, aceptando tokens emitidos para servicios completamente diferentes. La línea de defensa: fijar el algoritmo esperado en la llamada de verificación, obtener la clave de verificación de una fuente confiable (normalmente una URL JWKS en lista blanca en el momento de la configuración, no el propio jku del token), y validar exp, iss y aud como comprobaciones posteriores a la firma. Referencia: RFC 8725 — Mejores prácticas actuales para JWT.

Por qué el ataque de confusión de algoritmo sigue apareciendo en CVE: una familia extendida de vulnerabilidades JWS implica a un servidor que le pregunta a la biblioteca JWT “¿es válido este token?” y deja que la biblioteca elija el algoritmo de verificación del propio encabezado del token. Un atacante que conoce la clave RSA pública del servidor (que, por definición, es pública) puede crear un token firmado con HMAC-SHA256 usando los bytes de la clave pública RSA como secreto HMAC, establecer alg: HS256 en el encabezado, y muchas bibliotecas lo verificarán. La mitigación es bloquear la verificación al algoritmo que esperas — pásalo como argumento explícito a la llamada de verificación en lugar de dejar que el token lo nomine. La divulgación de 2015 de esto contra múltiples bibliotecas importantes (jsonwebtoken de Node, pyjwt de Python, varias implementaciones Java) es el cuento de advertencia estándar.

JWS desacoplado — cuando el contenido es demasiado grande para incrustar: RFC 7797 define un modo de “contenido desacoplado” donde el segmento central está vacío y el contenido se transmite fuera de banda (p. ej., como cuerpo HTTP, mientras el JWS está en un encabezado). Así es como algunas API financieras firman grandes cuerpos de solicitudes sin volver a codificar en base64 megabytes de JSON. La firma se calcula sobre los bytes del contenido original; solo cambia el formato de transmisión. Referencia: RFC 7515 — JSON Web Signature.