En este artículo
Que es un JWT?
Un JSON Web Token (JWT) es un formato de token compacto y seguro para URL utilizado para transmitir información de forma segura entre partes como un objeto JSON. Un JWT consta de tres partes codificadas en Base64URL separadas por puntos: cabecera.carga-util.firma. La cabecera especifica el algoritmo de firma, la carga util contiene las claims (datos), y la firma verifica que el token no ha sido alterado.
Los JWT permiten la autenticación sin estado: el servidor no necesita almacenar datos de sesión porque toda la información necesaria esta integrada en el propio token. Esto hace que los JWT sean ideales para sistemas distribuidos, microservicios y APIs donde el almacenamiento de sesiones agregaria complejidad y latencia.
Estructura de un JWT explicada
Cada JWT se compone de tres partes distintas, cada una con un proposito especifico en el ciclo de vida del token:
- Cabecera (Header) — un objeto JSON que especifica el tipo de token (typ: JWT) y el algoritmo de firma (alg: HS256, RS256, etc.), codificado en Base64URL
- Carga util (Payload) — un objeto JSON con claims como iss (emisor), sub (sujeto), exp (expiración), iat (fecha de emisión), y cualquier dato personalizado
- Firma (Signature) — creada firmando la cabecera y carga util codificadas con una clave secreta (HMAC) o clave privada (RSA/ECDSA), garantizando la integridad del token
La carga util no esta cifrada — cualquiera puede decodificarla y leerla. Nunca almacene información sensible como contraseñas o números de tarjetas de credito en la carga util de un JWT. La firma solo garantiza que los datos no han sido modificados, no que estan ocultos.
Algoritmos de firma
La eleccion del algoritmo de firma determina como se crea y verifica la firma del JWT. Hay tres familias principales:
- HMAC (HS256, HS384, HS512) — algoritmos simetricos que usan la misma clave secreta para firmar y verificar. Simples de implementar, ideales para configuraciones de un solo servidor
- RSA (RS256, RS384, RS512) — algoritmos asimetricos que usan una clave privada para firmar y una publica para verificar. Ideales para sistemas distribuidos
- ECDSA (ES256, ES384, ES512) — algoritmos asimetricos que usan criptografia de curva eliptica. Ofrecen la misma seguridad que RSA con claves mas pequeñas y computación mas rápida
Para la mayoría de aplicaciones web, HS256 es suficiente cuando el emisor y consumidor del token son el mismo servidor. Elija RS256 o ES256 cuando los tokens deban ser verificados por terceros o entre diferentes servicios.
Pruébalo gratis — sin registro
Crear y firmar JWTs →Codificación vs decodificación
Codificar un JWT significa crear un nuevo token ensamblando la cabecera, la carga util y generando la firma con su clave secreta o privada. Esto se hace tipicamente en el lado del servidor durante el inicio de sesión o la renovación del token.
Decodificar un JWT puede significar dos cosas: extraer las claims de la carga util sin verificar la firma (util para leer metadatos del token en el cliente), o verificar completamente la firma para confirmar que el token es autentico. Los sistemas en producción siempre deben verificar la firma antes de confiar en las claims.
Casos de uso comunes
Los JWT se han convertido en el estandar para patrones modernos de autenticación y autorización en aplicaciones web y moviles:
- Autenticación de API — los clientes incluyen el JWT en el encabezado Authorization (Bearer token) con cada solicitud, permitiendo al servidor verificar la identidad sin consultas a la base de datos
- Tokens de acceso OAuth 2.0 — los proveedores OAuth emiten JWT como tokens de acceso que llevan información de alcance y permisos
- Comunicación entre microservicios — los servicios pasan JWT entre si para propagar la identidad del usuario y los permisos a traves de los limites del servicio
- Inicio de sesión unico (SSO) — un proveedor de identidad central emite un JWT que multiples aplicaciones aceptan, permitiendo autenticación unica
Mejores practicas de seguridad
Los JWT son potentes pero requieren una implementación cuidadosa para evitar trampas de seguridad comunes:
- Establecer tiempos de expiración cortos — use claims exp de 15 minutos a 1 hora para tokens de acceso e implemente rotación de tokens de actualización
- Nunca almacene datos sensibles en la carga util — las cargas utiles JWT solo estan codificadas en Base64URL, no cifradas
- Siempre valide todas las claims — verifique exp, iss, aud y cualquier claim personalizada en cada solicitud
- Use exclusivamente HTTPS — transmita JWT solo a traves de conexiones cifradas
- Rechace el algoritmo "none" — siempre valide que el encabezado alg coincida con su algoritmo esperado
Preguntas frecuentes
Cual es la diferencia entre JWT y cookies de sesión?
Las cookies de sesión almacenan un ID de sesión en el cliente mientras los datos reales de sesión residen en el servidor. Los JWT son autocontenidos — todos los datos estan en el token mismo. Esto hace que los JWT sean sin estado y mas fáciles de escalar horizontalmente, pero mas dificiles de revocar.
Como revoco un JWT antes de que expire?
Como los JWT son sin estado, no hay un mecanismo de revocacion incorporado. Las estrategias comunes incluyen: mantener una lista negra de tokens, usar tokens de acceso de corta duración con rotación de tokens de actualización, o almacenar una versión del token en el registro del usuario.
Hay un limite de tamaño para los JWT?
No hay un limite formal en la especificación JWT, pero existen limites practicos. La mayoría de los servidores HTTP limitan los encabezados a 8 KB. Se recomienda mantener los tokens por debajo de 4 KB.