JWT es solo Base64 en un abrigo — Descódelo en segundos en línea

Estás mirando una pestaña de red. Hay un encabezado de solicitud que dice Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c y tu primera reacción es: "¿Qué es esto incluso?"

Buena noticia: la mayoría de esa cadena es simplemente Base64. El bloque feo parece vestido con un abrigo de campo, fingiendo ser más misterioso de lo que es. Vamos a quitárselo.

¿Qué es realmente un JWT?

Un JSON Web Token es tres fragmentos codificados en Base64url unidos con puntos:

• Encabezamiento – algoritmo y tipo de token (por ejemplo. {"alg":"HS256","typ":"JWT"})
• Carga útil – las declaraciones: ID de usuario, roles, vencimiento, cualquier cosa que el servidor decidió empaquetar
• Firma – la parte que realmente impone seguridad

El encabezado y el cuerpo son no criptografiados. Son codificados en Base64url, lo que significa que cualquier persona con el token puede leerlos — sin clave necesaria. Solo la firma impide alteraciones: cambiar un solo carácter en el cuerpo anula el token.

Para descodificar el cuerpo ahora: toma el segundo fragmento (entre los dos puntos), pégalo en un decodificador de Base64y verás JSON plano. Eso es todo. Esa es la magia.

Cómo descodificar un JWT en segundos

La forma más rápida: pega tu token en el decodificador de JWT en IOTools. Divide los tres fragmentos, descodifica cada uno y muestra el encabezado y el cuerpo como JSON formateado — sin cuenta, sin configuración, sin "iniciar sesión para desbloquear el decodificador".

Lo que verás inmediatamente en un payload típico:

• sub – sujeto (normalmente ID de usuario)
• iat – timestamp de emisión (epoca Unix)
• exp – timestamp de vencimiento
• iss – emisor
• Cualquier declaración personalizada que tu API incluya: roles, permisos, nivel de plan, etc.

Si solo necesitas saber si un token ha expirado sin configurar un completo decodificador, el verificador de expiración de JWT lee el exp claim y te dice exactamente cuánto tiempo le queda — o cuándo murió.

Los tres problemas que destruyen a los desarrolladores

1. El vencimiento que olvidaste verificar

El exp el campo es simplemente un número en el payload — el servidor debería validarlo, pero muchos códigos antiguos no lo hacen, o tienen un error en el manejo de zonas horarias. Si los usuarios se desconectan de forma misteriosa (o permanecen conectados por siempre), descodifica el token y compara exp con el timestamp actual Unix. El verificador de expiración lo hace en un solo clic.

2. Confusión con el algoritmo

El campo del encabezado indica al verificador qué algoritmo usar. Algunas bibliotecas de JWT antiguas aceptaban alg y omitían la verificación completa — eliminaban la firma y trataban cualquier cuerpo como válido. Esto es un ataque conocido. Asegúrate siempre de que tu biblioteca verifique una lista específica de algoritmos y rechace {"alg":"none"} Otra variante: RS256 (asimétrico) vs HS256 (simétrico). Un atacante que conozca tu clave pública puede forjar un token cambiando el encabezado a none.

y firmándolo con la clave pública como secreto — si la biblioteca confía naïvemente en el campo del encabezado HS256 el fix: configura tu biblioteca con un algoritmo explícito, no con "lo que diga el token". alg 3. Secrets en el cuerpo

Como el cuerpo está codificado en Base64 y no encriptado, cualquier cosa que pongas allí es legible por el cliente (y por cualquier persona que intercepte el token por HTTP plano, aunque estés usando HTTPS en todos lados, ¿verdad?). No pongas contraseñas, datos personales (PII) ni detalles internos en declaraciones de JWT. El cuerpo está destinado para metadatos de autorización — no como lugar para almacenar datos sensibles.

Descodifica un token de tu propia app y mira qué hay dentro. Tal vez te sorprenda lo que un desarrollador anterior coloco hace años.

JWT vs Tokens de sesión: ¿Qué es realmente diferente?

La discusión permanente. Aquí tienes una comparación directa:

JWT

	Token de sesión	Dónde se almacena el estado
Dentro del token (sin estado)	En el lado del servidor (base de datos o memoria)	Revocación
Difícil — el token es válido hasta	a menos que mantengas una lista de bloqueo exp Fácil — basta eliminar el registro de sesión	Ideal para sistemas distribuidos; no se necesita un almacenamiento compartido de sesiones
Escalabilidad	Requiere sesiones pegadas o almacenamiento compartido (Redis, etc.)	Visibilidad del cuerpo
El cliente puede leer las declaraciones (no están encriptadas)	Oscuro para el cliente	Riesgo de almacenamiento
localStorage es vulnerable a XSS; el cookie httpOnly es más seguro	cookie httpOnly (enfoque estándar)	Tamaño del token
Más grande — lleva todas las declaraciones inline	Pequeño — solo un ID	Mejor para
APIs, microservicios, autenticación entre dominios	Aplicaciones web tradicionales que se renderizan en el servidor	Ni uno ni el otro es universalmente mejor. Los JWT brillan cuando necesitas autenticación sin estado entre múltiples servicios. Los tokens de sesión son más simples cuando controlas toda la pila y necesitas revocación inmediata (por ejemplo, "cerrar sesión en todas partes" en caso de incidente de seguridad).

Depuración de JWTs en flujos reales

Aquí está la secuencia típica cuando algo falla en una API que usa JWTs:

Copia el token

1. del request fallido (encabezado de autorización, parámetro de consulta o cookie — donde tu API lo coloque) Pégalo en el
2. para ver las declaraciones brutas decodificador de JWT — ¿el token ha expirado? Usa el
3. Verificar exp si no quieres hacer cálculos de timestamp en tu mente verificador de expiración — ¿el emisor y el público coinciden con lo que espera tu servicio?
4. Verificar iss y aud Verifica el algoritmo
5. en el encabezado — ¿coincide con la configuración del servidor? Verifica el formato de la firma
6. — ¿tres partes? ¿dos? Un token alterado a veces aparece como dos partes sin firma La mayoría de la depuración de JWTs termina en el paso 3. El token fue emitido con un TTL corto, fue cachéado en algún lugar y llegó expirado. Esto es aburrido y común.

La firma: la única parte que importa

La firma se calcula como:

. El servidor la genera al emitir el token. Al validarla, lo recalculará y lo comparará. Si el cuerpo ha sido modificado en cualquier momento — incluso un carácter— el hash no coincidirá y el token será rechazado. HMACSHA256(base64url(header) + "." + base64url(payload), secret)Es por eso que descodificar un JWT para leer las declaraciones es seguro y sencillo, pero forjar uno sin el secreto no es posible. El Base64 es el disfraz; la firma es el candado en la puerta.

Para algoritmos asimétricos (RS256, ES256), la clave de firma es una clave privada que nunca abandona el servidor de autenticación. La clave de verificación es una clave pública que cualquier servicio puede usar — sin necesidad de secreto compartido. Esta es la arquitectura correcta para microservicios donde varios servicios necesiten verificar tokens, pero solo uno debe emitirlos.

JWT es simplemente Base64 en un abrigo de campo — descódelo en línea en segundos 2

También te puede interesar