JWE

JWE (JSON Web Encryption, RFC 7516) es el marco de cifrado en la familia JOSE (JSON Object Signing and Encryption), hermano de JWS. Donde JWS firma un contenido (manteniéndolo legible pero protegido contra manipulaciones), JWE cifra el contenido (manteniendo su contenido confidencial).

Un token JWE en serialización compacta tiene cinco segmentos separados por puntos en lugar de los tres de JWT:

1. Encabezado — JSON que declara los algoritmos de cifrado.
2. Clave de cifrado de contenido (CEK) cifrada — la clave simétrica usada para el contenido, a su vez cifrada con la clave del destinatario.
3. Vector de inicialización (IV) — nonce aleatorio por cifrado.
4. Texto cifrado — el contenido cifrado real.
5. Etiqueta de autenticación — para modos AEAD; verifica que el texto cifrado no haya sido manipulado.

JWE usa un esquema híbrido: una clave simétrica (la CEK) cifra el contenido (porque la criptografía simétrica es rápida), y luego una clave asimétrica cifra la CEK (porque la asimétrica es la única forma de mantener las claves intercambiables sin un secreto compartido). Algoritmos estándar: RSA-OAEP para el envoltorio de clave, A256GCM para el cifrado del contenido.

Cuándo usar JWE frente a JWT: la mayoría de los sistemas de autenticación usan JWT (firmado pero no cifrado) porque las afirmaciones no son secretas — un token que contiene “sub: user_123, exp: ...” está bien para leer. Usa JWE cuando el token contiene un contenido genuinamente sensible (registros médicos, detalles financieros, datos de enrutamiento solo interno) y no puedes garantizar que los intermediarios no lo inspeccionen. La mayoría de los sistemas modernos prefieren mantener los datos sensibles en el servidor y usar un ID de sesión corto opaco en su lugar — más simple que JWE.

Ejemplo práctico

Un emisor de tokens necesita enviar una referencia de registro médico a un servicio posterior a través del navegador, pero el navegador no debe poder leerlo. El emisor crea un JWE: encabezado {"alg":"RSA-OAEP-256","enc":"A256GCM","cty":"JWT","kid":"recipient-2026"}, contenido {"patient_id":"P-12345","record_id":"R-78910"}. El emisor genera una CEK aleatoria de 256 bits, cifra el contenido con AES-256-GCM bajo esa clave (produciendo texto cifrado + etiqueta de autenticación de 128 bits), y cifra la CEK bajo la clave pública RSA del destinatario. La salida son cinco segmentos codificados en base64url unidos por puntos — unos 600-800 bytes en total. El destinatario desenvuelve en orden inverso: descifra la CEK con RSA usando su clave privada, descifra el contenido con AES-GCM usando la CEK, verifica que la etiqueta de autenticación coincide. Cualquier manipulación en cualquiera de los cinco segmentos falla la comprobación de la etiqueta de autenticación y el destinatario rechaza el token. El navegador que lleva el JWE en medio solo ve base64 opaco — los IDs de paciente/registro son inaccesibles.

Cuándo y por qué importa

JWE importa cuando un token tiene que atravesar intermediarios no confiables mientras lleva afirmaciones confidenciales — datos de pacientes, detalles de enrutamiento financiero, identificadores de usuarios internos — y la arquitectura tiene que usar un token en lugar de una sesión del lado del servidor. El error a evitar es usar JWE primero cuando una arquitectura más simple funciona: la mayoría de los flujos de autenticación se atienden mejor con JWT firmados que contienen solo referencias (un ID de usuario, un ID de sesión) que los intermediarios pueden ver sin problema, mientras que los datos sensibles permanecen en la base de datos del emisor. Usa JWE cuando los intermediarios están operativamente obligados a mantener el token pero están contractual o legalmente restringidos de leerlo — SSO federado entre organizaciones, intercambio de datos de salud entre proveedores, algunos flujos PSD2 de banca abierta. El segundo error es la elección incorrecta del algoritmo: RSA-OAEP con SHA-1 está obsoleto, RSA-OAEP-256 es la recomendación actual; A128CBC-HS256 aún es aceptable pero A256GCM es preferido para nuevos despliegues. Referencia: RFC 7518 — Algoritmos web JSON.

JOSE anidado — firmar y luego cifrar: para tokens que necesitan tanto autenticidad (origen demostrable) como confidencialidad, el patrón estándar es firmar y luego cifrar: el contenido primero se envuelve en un JWS, y luego el JWS completo se convierte en el contenido de un JWE. El campo de encabezado cty: "JWT" en el JWE externo indica al analizador que el contenido descifrado es en sí mismo un token JOSE a verificar. El orden inverso (cifrar y luego firmar) es menos seguro porque la firma estaría sobre texto cifrado que podría reproducirse entre destinatarios. La mayoría de las plataformas SSO empresariales que usan JWE (tokens de federación de Microsoft Azure AD, algunas API bancarias) usan firmar y luego cifrar como estándar. Referencia: RFC 7516 — JSON Web Encryption.