¿Qué es un JWT y por qué no deberías guardar secretos dentro?
Publicado el 2026-10-20 por frfrand
JWT explicado desde cero: header, payload y firma, diferencias con cifrado, expiración y precauciones de seguridad.
Un JWT es un formato de token que permite transportar afirmaciones o datos entre sistemas. Muchas aplicaciones lo utilizan para intercambiar información sobre sesiones y permisos. El nombre viene de JSON Web Token.
La advertencia más importante es esta: un JWT firmado normalmente no está cifrado. Que parezca una cadena ilegible no significa que sea un lugar seguro para guardar contraseñas.
Las tres partes que suelen aparecer
Un JWT compacto firmado suele contener tres segmentos separados por puntos:
encabezado.contenido.firmaEl encabezado indica información como el algoritmo. El contenido —o payload— lleva afirmaciones conocidas como claims. La firma permite comprobar integridad y autenticidad bajo determinadas condiciones, si se valida correctamente.
Los segmentos usan representaciones que pueden decodificarse. Por eso un identificador de usuario o una fecha de expiración puede leerse sin conocer una contraseña secreta.
¿Para qué sirve?
Imaginá que un usuario se autentica en una aplicación. El servidor puede emitir un token que otro componente valida para reconocer ciertas afirmaciones durante su vigencia.
En algunas arquitecturas eso simplifica la comunicación entre servicios. En otras, una sesión tradicional mantenida en el servidor resulta más sencilla y permite revocación inmediata con menos complicaciones.
No existe obligación de utilizar JWT solo porque desarrollás una API moderna.
¿Qué significan exp, iss y aud?
exp es una afirmación habitual sobre expiración, iss identifica al emisor y aud señala la audiencia prevista.
Una implementación segura no se limita a comprobar la firma. También debe verificar qué emisor es confiable, para qué audiencia se emitió el token, si ya expiró y si los permisos declarados son pertinentes para la operación.
Un token válido para otra API no debería poder reutilizarse indiscriminadamente en la tuya.
¿JWT significa que no necesito base de datos?
No necesariamente. Tu aplicación puede seguir consultando permisos, estados de cuentas o recursos. Un usuario puede perder acceso a un proyecto antes de que expire el token recibido.
Si toda la autorización depende de afirmaciones desactualizadas, podrías permitir acciones que ya fueron revocadas. La política de expiración y el mecanismo de revocación deben diseñarse pensando en ese riesgo.
¿Dónde se guarda el token en el navegador?
Es una decisión con compromisos. Guardarlo en almacenamiento accesible por JavaScript puede aumentar el impacto de ciertos ataques XSS. Las cookies con atributos adecuados pueden reducir determinados riesgos, pero también deben considerarse CSRF, alcance de dominio y duración.
No existe una respuesta única sin conocer la arquitectura. Evitá repetir recetas del tipo «JWT siempre en localStorage» o «JWT siempre en cookies» sin evaluar el modelo de amenazas.
Errores frecuentes
Poner secretos en el payload. Si el token no está cifrado, esos datos son recuperables.
Aceptar algoritmos o emisores inesperados. La validación debe ser estricta y utilizar una configuración confiable.
Usar expiraciones excesivas sin revocación. Si el token se filtra, puede permitir acceso durante más tiempo del razonable.
Confundir JWT con OAuth. Uno es un formato; el otro es un marco de autorización. Pueden utilizarse juntos, pero no son sinónimos.
Un ejemplo en ArduMaker
Si una aplicación alojada en un VPS administrado desde ArduMaker utiliza tokens JWT, el servidor de la aplicación debe validarlos correctamente y comprobar permisos sobre cada recurso. El alojamiento no convierte automáticamente un token inseguro en confiable.
Para recordar: la firma de un JWT ayuda a comprobar su integridad, no a ocultar su contenido. La seguridad depende de cómo se emite, valida, almacena y revoca.
Fuentes: RFC 7519, JSON Web Token · Buenas prácticas de JWT en OWASP.