September 5, 2026
 |  No Comments

Un JSON Web Token (JWT) que está encriptado se llama JWE (JSON Web Encryption)

JWS (JSON Web Signature): Es el formato de JWT más común. Su contenido está codificado en Base64Url y firmado digitalmente. No oculta los datos (cualquiera los puede leer si decodifica el string), pero sí garantiza que no hayan sido alterados.

JWE (JSON Web Encryption): A diferencia del JWS, el contenido está cifrado/encriptado. Nadie puede leer los datos almacenados en el payload a menos que posea la clave privada o secreta correspondiente para descifrarlo

JWE es un estándar abierto (RFC 7516) que sirve para encriptar el contenido de un JSON para que solo la persona o servidor que posee la clave correspondiente pueda leerlo

A diferencia de un JWT común firmado (llamado técnicamente JWS – JSON Web Signature), donde cualquiera puede leer el contenido pero nadie puede alterarlo sin romper la firma, en JWE el contenido es totalmente confidencial (invisible) para cualquiera que no tenga la clave de desencriptación

Un token JWE tiene 5 partes codificadas en Base64URL separadas por 4 puntos

header.encrypted_key.initialization_vector.ciphertext.authentication_tag

Header (Encabezado): Indica qué algoritmo se usó para encriptar la clave y el contenido.

Encrypted Key: La clave simétrica de encriptación, protegida/encriptada con la clave del destinatario.

Initialization Vector (IV): Un valor aleatorio necesario para el algoritmo de encriptación simétrica.

Ciphertext (Texto cifrado): El contenido real (payload) totalmente encriptado e ilegible.

Authentication Tag: Una firma de autenticidad que garantiza que el mensaje encriptado no fue modificado ni manipulado

¿Cuándo usar JWE?

Se utiliza cuando los datos dentro del token no pueden ser vistos por terceros, ni siquiera por el navegador del cliente o servidores intermedios por los que pasa la petición.

  • Ejemplo: Si necesitas enviar un token que contenga información médica, un número de tarjeta de crédito o credenciales de acceso sensibles a través de un canal donde no quieres que ningún cliente o proxy pueda inspeccionar los datos internos

un JWE es un tipo de JWT

Por defecto, cuando la mayoría de los desarrolladores dicen “JWT”, se refieren a un JWS (firmado pero visible). Si a ese JWT lo encriptás para que nadie pueda leerlo, pasa a ser un JWE

¿Las credenciales de login se envían por JWE o JWT?

Ninguno de los dos.

Las credenciales de login (usuario y contraseña) no se envían dentro de un token, sino que se envían en un JSON normal dentro del cuerpo de la petición HTTP (POST /api/login):

{
  "email": "usuario@email.com",
  "password": "mi_contraseña_secreta"
}

Para proteger esas credenciales en tránsito, se confía en HTTPS (TLS/SSL), que encripta toda la comunicación entre el navegador/cliente y el servidor

¿Dónde entra el JWT o JWE entonces?

Un token no se usa para enviar las credenciales, sino que se genera como respuesta después de que el servidor validó la contraseña:

  1. Enviás credenciales: Mandás usuario y contraseña por POST seguro (HTTPS).
  2. El servidor valida: Comprueba en la base de datos si la clave es correcta.
  3. El servidor emite el Token: Genera un JWT (o JWE) y te lo devuelve.
  4. Usás el Token: En las siguientes peticiones, enviás ese token para identificarte

¿Cuándo usarías JWT (JWS) vs JWE en la respuesta?

  • Usás un JWT común (JWS) si: Solo querés enviar información estándar de sesión (ej. user_id, role, expira_en). No importa que el navegador pueda decodificarlo y ver el JSON, porque no hay datos secretos ahí y la firma evita que el cliente modifique su rol de user a admin.
  • Usás JWE si: Necesitás guardar dentro del token información extremadamente sensible que el cliente no debería poder leer bajo ninguna circunstancia (por ejemplo, claves de cifrado temporales, tokens de acceso a APIs de terceros o datos personales de salud).

Para la inmensa mayoría de los sistemas de login, debés usar un JWT común (JWS).

No hace falta complicarse con JWE salvo que tengas un requisito de confidencialidad muy extremo y muy específico.

El usuario envía usuario y clave por POST en un cuerpo JSON normal mediante HTTPS. HTTPS ya encripta toda la conexión, por lo que nadie en el camino puede interceptar las claves

El JWT guarda en su payload datos no sensibles de identificación, como:

{
  "sub": "user_12345",
  "name": "Axel",
  "role": "admin",
  "exp": 1750003600
}

Aunque el usuario o el navegador puedan decodificar el Base64 de ese token y leer "role": "admin", no pueden modificarlo, porque si intentan cambiar "admin" por otro valor, la firma (signature) del JWT se rompe y el servidor rechazará el token.

Usá JWE únicamente si: Necesitás guardar dentro del payload del token información confidencial que ni el propio cliente/navegador ni una extensión del navegador deberían poder leer (por ejemplo, tokens de API de terceros con alcance total, información médica sensible o claves privadas temporales

[Cliente]  --- (1) POST /login { user, pass } por HTTPS --->  [Servidor]
[Cliente]  <-- (2) Retorna JWT común (JWS) firmado --------  [Servidor]
[Cliente]  --- (3) GET /perfil [Header: Bearer <JWT>] ---->  [Servidor (Verifica firma)]

Complejidad criptográfica (Cómputo)

  • JWT común (JWS): Solo requiere firmar / verificar la firma. Esto usa algoritmos simétricos rápidos como HMAC-SHA256 (o asimétricos como RS256). Es una operación matemática muy ligera.
  • JWE: Requiere encriptar / desencriptar todo el payload. Por lo general usa un esquema híbrido: genera una clave simétrica al vuelo, encripta el contenido con algoritmos más pesados (como AES-GCM o AES-CBC), y luego encripta esa clave con una clave asimétrica (RSA o ECDH). El servidor tiene que hacer este proceso completo en cada petición HTTP que recibe.

¿Cuándo esa diferencia realmente importa?

  • En apps normales o medianas: La diferencia no la vas a notar. Un servidor moderno puede procesar miles de desencriptaciones JWE por segundo sin despeinarse.
  • En alta concurrencia / Microservicios (High Throughput): Si tu arquitectura procesa decenas de miles de peticiones por segundo y usás JWE en cada llamada interna entre microservicios, el consumo extra de CPU para desencriptar encabezados se vuelve notable y aumenta los costos de infraestructura (Cloud / Compute).

Es otra de las razones por las cuales la industria usa JWT tradicional (JWS) para el 99% de los casos: es más liviano, más rápido de validar y no satura la CPU sin necesidad

Views: 280
Tags: , , , , , , ,