JWTs: cuándo sí y cuándo no

JWT se volvió una respuesta automática para casi cualquier sistema con login. Si hay auth, alguien propone JWT. Si hay microservicios, también. Si hay frontend separado del backend, otra vez JWT. El problema es que muchas veces se elige por costumbre, no por necesidad, y ahí empiezan los dolores: revocación difícil, claves que hay que rotar bien, tokens que duran demasiado y una operación más compleja de lo que parecía al inicio.

No se trata de decir “no uses JWT” porque sí. Se trata de entender cuándo te simplifica la vida y cuándo te la complica. Si tu sistema necesita sesiones simples, revocación inmediata y control fino, un JWT mal usado puede ser peor que una sesión tradicional. Si, en cambio, necesitas validar identidad sin consultar una base central en cada request, o compartir claims entre varios servicios, ahí sí puede tener sentido. Vamos a aterrizarlo con ejemplos concretos.

Qué problema resuelve JWT de verdad

JWT significa JSON Web Token. En la práctica, es un formato compacto para transportar claims firmadas digitalmente. No es una sesión. No es una base de datos. No es un sistema de autenticación completo. Es un contenedor firmado que permite a otro servicio verificar que ciertos datos fueron emitidos por alguien confiable y no fueron alterados.

La ventaja principal es que el receptor puede validar el token sin llamar al servidor emisor en cada request, siempre que tenga la clave pública o el secreto correcto. Eso reduce dependencia entre servicios y evita que cada petición pase por una consulta de sesión central. Según la especificación de JWT en RFC 7519, el token puede incluir campos como sub, exp, iat y aud, que ayudan a controlar identidad, expiración y audiencia. Puedes revisar la base técnica en la RFC oficial y en la documentación de Auth0 sobre JWT: https://datatracker.ietf.org/doc/html/rfc7519 y https://auth0.com/docs/secure/tokens/json-web-tokens.

Dónde sí aporta valor

JWT suele encajar bien cuando necesitas una de estas cosas:

1. Autenticación entre varios servicios que no quieren depender de una sesión compartida.
2. APIs consumidas por apps móviles, SPAs o terceros, donde el backend solo necesita verificar firma y expiración.
3. Sistemas donde el token lleva claims útiles, por ejemplo rol, tenant o permisos básicos, y esos datos cambian poco.

Un ejemplo realista: tienes una app web, una app móvil y un API gateway. El usuario inicia sesión una vez y luego consume varios servicios. Si cada servicio tuviera que consultar una tabla central de sesiones en cada request, agregas latencia y un punto de fallo. Un JWT bien diseñado permite validar localmente y seguir operando incluso si el servicio de autenticación está temporalmente caído, siempre que el token siga siendo válido.

Dónde deja de ser buena idea

JWT empieza a perder sentido cuando lo usas como sustituto de todo. Si quieres revocar sesiones al instante, cerrar dispositivos específicos, cambiar permisos en tiempo real o invalidar tokens con facilidad, el enfoque se complica. El problema no es el formato; el problema es que el token vive fuera del servidor y, por diseño, no lo puedes “desfirmar”.

Eso significa que si emitiste un JWT válido por 24 horas, seguirá siendo válido hasta que expire, aunque el usuario cierre sesión en otro lado, aunque le roben el token o aunque cambies su rol en la base de datos. Puedes mitigar eso con listas de revocación, introspección o expiraciones cortas, pero ya estás construyendo mecanismos extra. Y esos mecanismos también cuestan operación.

El costo oculto: revocación, expiración y seguridad

El punto más incómodo de JWT es que la revocación no viene gratis. En un modelo de sesión tradicional, puedes borrar la sesión del servidor y listo. En JWT, el servidor receptor confía en la firma y en exp. Si el token sigue dentro de su ventana de validez, seguirá pasando validación.

Eso obliga a tomar decisiones desde el diseño. ¿Cuánto tiempo va a vivir el access token? ¿Vas a usar refresh tokens? ¿Vas a mantener una blacklist? ¿Qué haces si un usuario cambia de rol a mitad del día? Cada respuesta cambia la complejidad del sistema. Y si no defines esto desde el principio, terminas con un Frankenstein de middleware, cron jobs y tablas auxiliares.

Revocar no es imposible, pero sí más caro

Hay varias estrategias, y ninguna es gratis:

• Access tokens de vida corta, por ejemplo 5 a 15 minutos.
• Refresh tokens almacenados y revocables en servidor.
• Lista de tokens revocados por jti o por usuario.
• Rotación de claves con soporte para múltiples kid activos.

La combinación más común es: access token corto y refresh token con control en servidor. Eso reduce la ventana de abuso si se filtra un token, pero agrega otra pieza crítica: el refresh token sí debe poder revocarse y auditarse. En otras palabras, no eliminaste la complejidad, solo la moviste.

Seguridad práctica: el token no debe guardar secretos

JWT no está cifrado por defecto. Está firmado. Eso significa que cualquiera que tenga el token puede decodificar su contenido. No debería llevar contraseñas, secretos de negocio ni datos sensibles que no quieras exponer al cliente. A veces se ve gente metiendo email, nombre completo, flags internas y hasta datos de facturación. Eso es mala idea.

Si necesitas confidencialidad real, JWT no es la herramienta correcta por sí sola. Puedes usar JWE, pero ahí sube bastante la complejidad. En la mayoría de productos, la solución más sana es mantener el token pequeño: sub, iss, aud, exp, quizá scope o roles mínimos, y nada más.

Cuándo JWT sí te conviene

JWT tiene sentido cuando el beneficio operativo supera el costo de manejar su ciclo de vida. En términos simples: si te ahorra llamadas, desacopla servicios o facilita validación distribuida, puede ser una buena pieza de arquitectura. Si solo estás reemplazando una sesión tradicional porque “así lo hacen las APIs modernas”, probablemente no.

Un caso donde sí encaja: un backend con varios servicios internos, un gateway y clientes externos. El gateway valida el token, los servicios validan firma y claims, y el tiempo de expiración es corto. Ahí JWT evita que cada microservicio dependa de una base de sesiones central. Otro caso: integraciones B2B donde emites tokens firmados para que un tercero consuma tu API y pueda validar su origen.

Señales de que sí vale la pena

• Tienes varios servicios y quieres validación local sin round-trips por request.
• Los claims cambian poco durante la vida del token.
• Puedes tolerar una ventana corta de validez, por ejemplo menos de 15 minutos.
• Ya tienes resuelto refresh token, rotación de claves y auditoría.
• Necesitas interoperar con proveedores o plataformas que esperan JWT.

Señales de que no vale la pena

• Tu app es monolítica y solo necesitas login de usuario web.
• Necesitas logout inmediato en todos los dispositivos.
• Cambias permisos con frecuencia y el acceso debe reflejarse al instante.
• No quieres operar listas de revocación ni rotación de claves.
• Tu equipo todavía no domina bien sesiones, cookies seguras y CSRF.

En un monolito clásico, una cookie de sesión con HttpOnly, Secure y SameSite suele ser más simple y más fácil de invalidar. No necesitas forzar JWT solo porque el frontend esté separado. Si tu backend sirve la app y la API, la sesión tradicional puede ser más robusta y menos costosa de mantener.

Cómo decidir sin caer en complejidad innecesaria

La decisión no debería partir de la moda, sino de cómo operas el sistema. Si tu prioridad es revocación inmediata, auditoría fina y control centralizado, una sesión tradicional suele ganar. Si tu prioridad es validación distribuida y menor dependencia del servidor de auth en cada request, JWT puede ser útil.

Hay una regla práctica que usamos bastante: si no puedes explicar con claridad cómo vas a revocar un token robado en menos de 15 minutos, todavía no tienes resuelto el diseño. No significa que JWT esté mal; significa que te falta una estrategia de seguridad completa.

Checklist de decisión

1. Define el tipo de cliente: web, mobile, terceros o servicios internos.
2. Define el tiempo de vida del access token: 5, 10 o 15 minutos suele ser común en sistemas sensibles.
3. Decide si habrá refresh token y dónde se guarda.
4. Define cómo rotarás claves sin tumbar sesiones activas.
5. Diseña revocación: por usuario, por dispositivo o por token individual.
6. Mide el costo operativo de mantener todo eso en producción.

Si al final de ese checklist la respuesta es “solo quiero login y logout”, probablemente JWT no sea la mejor herramienta. Si la respuesta es “necesito tokens firmados para varios servicios y puedo asumir expiración corta”, entonces sí tiene sentido.

Tabla comparativa rápida

Buenas prácticas si decides usar JWT

Si decides usar JWT, no lo hagas a medias. El mayor error es emitir tokens largos, meter demasiada información y dejar la revocación para después. Eso termina en incidentes o en un sistema difícil de operar.

Lo mínimo que deberías cuidar es esto: firma fuerte, expiración corta, claims mínimos, refresh token separado y rotación de claves planificada. También conviene registrar jti o algún identificador único para poder rastrear eventos y, si hace falta, invalidar tokens específicos.

Recomendaciones concretas

• Usa exp siempre. No emitas tokens sin expiración.
• Mantén el access token corto, idealmente entre 5 y 15 minutos si el riesgo es alto.
• Guarda refresh tokens de forma segura y revócalos en servidor.
• Rota claves con soporte para múltiples kid activos durante la transición.
• No guardes datos sensibles dentro del token.
• Valida iss y aud para evitar reutilización fuera del contexto esperado.

Si trabajas con cookies en el navegador, recuerda que el almacenamiento también importa. Un JWT en localStorage suele ser una mala idea porque expone el token a XSS. Para web, muchas veces es mejor poner el token en una cookie HttpOnly y proteger el flujo completo. La documentación oficial de OWASP sobre sesiones y tokens es una referencia útil: https://cheatsheetseries.owasp.org/.

Ejemplo de payload mínimo

{
  "sub": "user_12345",
  "iss": "auth.example.com",
  "aud": "api.example.com",
  "iat": 1718000000,
  "exp": 1718000900,
  "jti": "0d4f7b9c-8d7a-4b0f-9f3a-1d2b3c4e5f60",
  "scope": "read:orders write:profile"
}

Ese payload ya te da identidad, emisor, audiencia, expiración y un identificador único. No necesitas meter nombre, correo, dirección ni banderas internas si no son estrictamente necesarias para validar la request.

Tabla resumen

JWT no es malo. Tampoco es la respuesta universal. Si lo usas donde aporta validación distribuida, interoperabilidad y menos dependencia entre servicios, puede ser una herramienta muy útil. Si lo usas para evitar pensar en sesiones, revocación y claves, te va a complicar bastante más de lo que te ayuda.

La pregunta correcta no es “¿deberíamos usar JWT?”. La pregunta correcta es “¿qué problema exacto estamos resolviendo y cuánto cuesta operarlo?” Si respondes eso con honestidad, vas a elegir mejor y vas a evitar una clase entera de problemas de seguridad y mantenimiento.