RunToolz iconRunToolz
Welcome to RunToolz!
JWTSeguridadAutenticación

JWTs: Qué Hay Realmente en Esas Cadenas Largas

JSON Web Tokens decodificados. Cómo funcionan, qué contienen y errores comunes de seguridad.

RunToolz Team26 de enero de 20263 min read

Ves una cadena como eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0.dozjgNryP4J3jVmNHl0w5N_XgL0n3I9PlFUP0THsR8U en tu sistema de autenticación.

¿Qué es eso? Es un JWT: tres bloques codificados en Base64 separados por puntos. Y puedes leerlo sin ninguna clave especial.

Las Tres Partes

Encabezado: Algoritmo y tipo de token

{"alg": "HS256", "typ": "JWT"}

Carga útil: Los datos reales (claims)

{"sub": "1234567890", "name": "John", "iat": 1516239022}

Firma: Verificación de que nada fue alterado

¿Quieres probarlo tú mismo?Decodificar JWT

Los JWTs No Están Encriptados

Este es el grande. Cualquiera puede decodificar un JWT y leer su contenido. Base64 es codificación, no encriptación.

No pongas secretos en JWTs. IDs de usuario, permisos, tiempos de expiración: bien. Contraseñas, tarjetas de crédito, datos privados: nunca.

Claims Estándar

iss — Emisor. Quién creó este token.

sub — Sujeto. Usualmente el ID de usuario.

exp — Expiración. Timestamp Unix cuando el token se vuelve inválido.

iat — Emitido en. Cuándo se creó el token.

aud — Audiencia. Quién debería aceptar este token.

Los claims personalizados también funcionan. Agrega los datos que tu aplicación necesite.

Cómo Funcionan las Firmas

La firma prueba que el token no ha sido modificado.

Servidor crea token → firma con clave secreta → envía al cliente. Cliente envía token de vuelta → servidor verifica firma → confía en el contenido.

Si alguien cambia la carga útil, la firma no coincidirá. El servidor lo rechaza.

Pero el servidor debe verificar la firma. JWTs sin verificación son teatro de seguridad.

Errores Comunes de Seguridad

No verificar firmas. Algo de código decodifica JWTs sin verificar la firma. Cualquiera puede falsificar tokens.

Usar secretos débiles. secret123 no es un secreto. Usa cadenas largas y aleatorias.

Ignorar expiración. Siempre verifica exp. Los tokens deberían tener vidas cortas.

Confusión de algoritmo. El campo alg dice cómo verificar. Los atacantes pueden configurarlo en none y saltarse la verificación si tu código confía en el encabezado.

Almacenar datos sensibles. Cualquiera con el token puede leer la carga útil. Mantén secretos del lado del servidor.

Cuándo Usar JWTs

Autenticación sin estado. El servidor no necesita almacenar sesiones. El token contiene todo lo necesario.

Microservicios. Los servicios pueden verificar tokens sin llamar al servidor de autenticación.

Inicio de sesión único. Compartir autenticación entre dominios.

Cuándo No Usar JWTs

Aplicaciones simples. Las cookies de sesión son más simples y más difíciles de estropear.

Necesidad de invalidar inmediatamente. Los JWTs son válidos hasta la expiración. Revocar requiere infraestructura extra.

Cargas útiles grandes. Cada solicitud lleva el token completo. Tokens grandes significan más ancho de banda.

Tokens de Actualización

Los tokens de acceso deberían ser de corta duración (minutos a horas). Los tokens de actualización obtienen nuevos tokens de acceso sin re-autenticación.

Almacena tokens de actualización de forma segura. Son de larga duración y poderosos.


Los JWTs son convenientes pero requieren cuidado. Entiende qué contienen, verifica firmas apropiadamente, establece expiraciones cortas y nunca pongas datos sensibles en la carga útil.