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 informacion 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 autenticacion sin estado: el servidor no necesita almacenar datos de sesion porque toda la informacion 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 (expiracion), iat (fecha de emision), 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 informacion sensible como contrasenas o numeros 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 pequenas y computacion mas rapida
Para la mayoria 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 →Codificacion vs decodificacion
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 sesion o la renovacion 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 produccion 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 autenticacion y autorizacion en aplicaciones web y moviles:
- Autenticacion 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 informacion de alcance y permisos
- Comunicacion 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 sesion unico (SSO) — un proveedor de identidad central emite un JWT que multiples aplicaciones aceptan, permitiendo autenticacion unica
Mejores practicas de seguridad
Los JWT son potentes pero requieren una implementacion cuidadosa para evitar trampas de seguridad comunes:
- Establecer tiempos de expiracion cortos — use claims exp de 15 minutos a 1 hora para tokens de acceso e implemente rotacion de tokens de actualizacion
- 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 sesion?
Las cookies de sesion almacenan un ID de sesion en el cliente mientras los datos reales de sesion 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 faciles 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 duracion con rotacion de tokens de actualizacion, o almacenar una version del token en el registro del usuario.
Hay un limite de tamano para los JWT?
No hay un limite formal en la especificacion JWT, pero existen limites practicos. La mayoria de los servidores HTTP limitan los encabezados a 8 KB. Se recomienda mantener los tokens por debajo de 4 KB.