Qué es un JWT Token y cómo funciona: Guía completa para desarrolladores

JWT token es una de las formas más populares de autorización en aplicaciones web modernas. Se utiliza en API, aplicaciones móviles y servicios con arquitectura de microservicios porque permite trabajar sin almacenar sesiones en el servidor.

Antes, el servidor debía recordar a cada usuario (mediante sesiones), pero con JWT todo funciona de otra manera: toda la información se transmite junto con la solicitud. Esto hace el sistema más rápido, fácil de escalar y más conveniente para servicios distribuidos.

En este artículo veremos qué es un JWT token, cómo funciona, de qué está compuesto y en qué se diferencia de las sesiones clásicas.

¿Qué es un JWT token en palabras sencillas?

JWT token es una cadena especial que almacena información sobre el usuario y se utiliza para su identificación sin necesidad de guardar datos en el servidor. JWT significa JSON Web Token.

En otras palabras, es un "pase digital" que recibes después de iniciar sesión. En vez de que el servidor verifique al usuario en la base de datos cada vez, simplemente revisa el token y entiende quién eres y qué permisos tienes.

JWT se usa activamente en aplicaciones web modernas, móviles y API. Por ejemplo:

• al iniciar sesión en un sitio
• al autorizarse a través de aplicaciones
• al trabajar con REST API

La idea principal de JWT es que toda la información se almacena dentro del token, no en el servidor. Esto hace el sistema más rápido y fácil de escalar.

Un token normalmente se ve como una cadena larga, separada por puntos, por ejemplo:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Aunque parece una cadena aleatoria, dentro contiene:

• información sobre el usuario (ID, rol)
• fecha de expiración
• firma que protege los datos contra manipulación

Importante: JWT no encripta los datos, solo los codifica. Esto significa que el contenido puede ser descifrado, pero no modificado sin romper la firma.

JWT se popularizó porque permite la autorización sin sesiones. El servidor no necesita almacenar el estado del usuario: toda la información ya está en el token.

¿Cómo funciona un JWT token?

El funcionamiento de JWT token gira en torno a una idea sencilla: el servidor emite el token una vez, y luego simplemente lo verifica en cada solicitud, sin guardar el estado del usuario.

Paso a paso:

1. El usuario introduce su login y contraseña. Estos datos se envían al servidor, que los verifica (por ejemplo, consultando la base de datos).
2. Si los datos son correctos, el servidor crea un JWT token que incluye:
   • ID de usuario
   • rol (por ejemplo, user o admin)
   • fecha de expiración (expiration time)
3. El token se envía al cliente -al navegador o la app-.

Opciones de almacenamiento:

• localStorage
• sessionStorage
• cookie (normalmente HttpOnly por seguridad)

Luego empieza la etapa clave: su uso. Cada solicitud posterior al servidor se envía con el token, normalmente en el encabezado:

Authorization: Bearer <token>

El servidor, al recibir la solicitud:

1. Extrae el token
2. Verifica la firma
3. Comprueba la expiración
4. Extrae los datos del payload

Si todo es correcto, el usuario se considera autorizado y la solicitud se ejecuta.

Importante: el servidor no guarda ninguna información del usuario entre solicitudes. Todo lo necesario ya está en el token.

Por eso se llama enfoque stateless -sin estado-.

Este mecanismo es especialmente útil para:

• API
• microservicios
• arquitecturas distribuidas

Además, JWT suele usarse junto con OAuth. Puedes leer más en la guía sobre cómo funciona OAuth 2.0 y la seguridad en el inicio de sesión.

Estructura de un JWT token

Un JWT token consta de tres partes separadas por puntos:

header.payload.signature

Cada parte se codifica en Base64, por lo que el token parece una cadena de caracteres, pero en realidad tiene una estructura legible.

1. Header (encabezado)

Contiene información sobre el tipo de token y el algoritmo de firma.

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

• alg - algoritmo de firma (por ejemplo, HMAC SHA-256)
• typ - tipo de token

2. Payload (carga útil)

Es la parte principal del token, donde se almacena la información.

{
  "userId": 123,
  "role": "admin",
  "exp": 1712345678
}

Pueden incluirse:

• datos del usuario
• permisos de acceso
• fecha de expiración (exp)
• hora de creación (iat)

Atención: el payload no está cifrado, solo codificado. Cualquiera puede leerlo.

3. Signature (firma)

La parte más importante, que protege el token de falsificaciones.

La firma se crea a partir de:

• header
• payload
• clave secreta (en el servidor)

Si alguien intenta modificar los datos del token, la firma no coincidirá y el servidor rechazará la solicitud.

En resumen, JWT es un contenedor autosuficiente de datos y protección. El servidor no necesita consultar la base de datos para saber quién es el usuario: toda la información ya está en el token.

Autorización y autenticación con JWT: ¿cuál es la diferencia?

Al trabajar con JWT, a menudo se confunden los términos autenticación y autorización. Están relacionados, pero realizan funciones diferentes.

Autenticación

Es el proceso de verificar la identidad del usuario.

En otras palabras, el sistema responde: ¿quién eres?

Ejemplo:

• el usuario introduce login y contraseña
• el servidor verifica los datos
• si todo es correcto, el usuario queda autenticado

En esta etapa normalmente se genera el JWT token.

Autorización

Es el siguiente paso. El sistema responde: ¿qué puedes hacer?

Por ejemplo:

• el usuario estándar puede leer datos
• el administrador puede modificarlos

Esta información se guarda dentro del JWT, generalmente en el payload (por ejemplo, en el campo role).

¿Cómo participa JWT en estos procesos?

1. El usuario se autentica (inicia sesión)
2. El servidor emite el JWT token
3. El token ya incluye los permisos de acceso
4. En cada solicitud, el servidor realiza la autorización leyendo los datos del token

Es decir, JWT une ambos procesos:

• confirma la identidad
• almacena los permisos de acceso

Importante: el JWT en sí no realiza la autenticación; solo almacena el resultado tras verificar al usuario.

JWT vs sesiones: ¿en qué se diferencian?

Para entender el valor de JWT, es importante compararlo con el enfoque clásico: las sesiones.

¿Cómo funcionan las sesiones?

Tras iniciar sesión, el servidor:

• crea un registro en memoria o en la base de datos
• asigna un session ID al usuario
• envía este ID en una cookie

En cada solicitud posterior:

• el navegador envía el session ID
• el servidor busca los datos en el almacenamiento
• determina quién es el usuario

Es decir, el servidor mantiene el estado del usuario.

¿Cómo funciona JWT?

En vez de guardar datos en el servidor:

• el servidor crea un token con información
• lo envía al cliente
• el cliente almacena el token
• en cada solicitud lo reenvía

El servidor no busca nada en la base de datos, solo verifica el token.

Diferencias clave

1. Almacenamiento de datos
   • Sesiones: en el servidor
   • JWT: dentro del token
2. Escalabilidad
   • Sesiones: más complicado (requiere almacenamiento compartido)
   • JWT: más sencillo (los servidores son independientes)
3. Rendimiento
   • Sesiones: acceso constante a la base o memoria
   • JWT: solo comprobación de firma
4. Seguridad
   • Sesiones: se pueden invalidar en el servidor
   • JWT: es más difícil revocar (si el token ya fue emitido)

¿Cuándo es mejor usar JWT?

• API y microservicios
• aplicaciones móviles
• sistemas distribuidos
• autorización mediante servicios externos

¿Cuándo es mejor usar sesiones?

• sitios web sencillos
• renderizado del lado del servidor (SSR)
• cuando se requiere control estricto de sesión
• cuando es importante revocar acceso rápidamente

Conclusión clave: JWT es ideal para flexibilidad y escalabilidad; las sesiones, para control y simplicidad en la gestión.

Access Token y Refresh Token: ¿cómo funciona la combinación?

En aplicaciones reales, casi nunca se usa JWT solo. En cambio, se emplea una combinación de dos tokens: access token y refresh token, para equilibrar seguridad y comodidad.

Access token

Es el token principal que se utiliza en las solicitudes.

• vida corta (por ejemplo, 5-30 minutos)
• se envía en cada solicitud
• contiene información del usuario

Si se roba el access token, el atacante solo podrá usar el sistema durante un tiempo limitado.

Refresh token

Es un token auxiliar para renovar el access token.

• vida más larga (días o semanas)
• no se usa en solicitudes normales
• se almacena de forma más segura (generalmente en una cookie HttpOnly)

¿Cómo funciona juntos?

1. El usuario inicia sesión
2. El servidor emite:
   • access token
   • refresh token
3. El usuario realiza solicitudes con el access token
4. Cuando el access token expira:
   • el cliente envía el refresh token al servidor
   • el servidor lo verifica
   • emite un nuevo access token
5. El usuario continúa trabajando sin tener que volver a iniciar sesión

¿Por qué no usar solo un JWT?

• Si el token vive mucho tiempo:
  • es cómodo de usar
  • pero si se filtra, es un gran riesgo
• Si el token es corto:
  • es seguro
  • pero molesto para el usuario (se cierra sesión frecuentemente)

La combinación de access + refresh token resuelve este problema:

• token corto para seguridad
• token largo para comodidad

Punto de seguridad importante

El refresh token suele:

• guardarse en cookies HttpOnly
• no estar accesible desde JavaScript
• estar protegido contra ataques XSS

Este enfoque se usa en casi todos los sistemas de autorización modernos.

Seguridad de los JWT tokens

JWT se considera seguro, pero solo si se implementa correctamente. Los errores pueden llevar a vulnerabilidades graves.

¿Por qué no se puede falsificar un JWT?

La principal protección de JWT es la firma. Cuando el servidor crea un token:

• lo firma con una clave secreta
• el cliente no conoce esa clave

En cada solicitud el servidor:

• recalcula la firma
• la compara con la original

Si los datos del token han sido alterados, la firma no coincidirá y se rechazará el acceso.

El mayor riesgo: robo del token

El JWT no puede ser "adivinado", pero sí robado. Si un atacante obtiene el token, podrá:

• enviar solicitudes en nombre del usuario
• acceder a los datos

El servidor no puede distinguirlo del usuario real.

¿Dónde guardar el JWT de forma segura?

Las opciones de almacenamiento afectan mucho la seguridad:

1. localStorage
   • fácil de usar
   • vulnerable a ataques XSS
2. sessionStorage
   • algo más seguro
   • aún accesible desde JavaScript
3. cookie HttpOnly (mejor opción)
   • no accesible por JavaScript
   • protegido contra XSS
   • manejada automáticamente por el navegador

Errores frecuentes de principiantes

1. Vida del token demasiado larga
   • Si dura semanas, es un riesgo.
2. Guardar datos sensibles
   • Nunca almacenar contraseñas, datos personales o información secreta en el JWT.
3. No usar HTTPS
   • Transmitir el token por HTTP es casi garantía de fuga.
4. No tener mecanismo de revocación
   • Como es difícil "cancelar" un JWT, usa tokens de vida corta y refresh tokens.

Resumen de seguridad

JWT es seguro si:

• se usa HTTPS
• el token vive poco tiempo
• se emplea la combinación access + refresh
• los datos en el token son mínimos

¿Cuándo conviene utilizar JWT?

JWT es una herramienta poderosa, pero no sirve para todo. Es importante saber cuándo aporta ventajas reales.

¿Cuándo es buena elección JWT?

1. SPA (Single Page Application)
   • React, Vue, Angular
   • frontend y backend separados
   • muchas solicitudes API
   • no hay sesiones clásicas

   Ideal porque:

   • no requiere almacenamiento de estado
   • fácil de enviar en cada solicitud
2. Aplicaciones móviles
   • iOS y Android
   • no hay cookies estándar como en el navegador
   • necesidad de un mecanismo sencillo de autorización

   JWT resuelve esto:

   • se almacena en el dispositivo
   • se envía en cada solicitud
3. API y microservicios
   • muchos servicios
   • no hay un servidor único de sesiones

   JWT permite:

   • no almacenar estado
   • verificar usuarios fácilmente en cualquier servicio
4. Autorización mediante servicios externos
   • inicio de sesión con Google u otras redes sociales

   En estos casos se suele usar JWT junto con OAuth. Más detalles en la guía sobre OAuth 2.0 y la seguridad en el inicio de sesión.

¿Cuándo NO es buena elección JWT?

1. Sitios sencillos
   • proyectos pequeños
   • renderizado en servidor (SSR)

   Las sesiones son más simples y seguras.

2. Cuando necesitas revocar acceso rápidamente
   • es difícil invalidar JWTs

   Si es clave cerrar sesión de inmediato o controlar sesiones, usa sesiones clásicas.

3. Altos requisitos de seguridad
   • bancos, servicios corporativos
   • se requiere control total de cada sesión

   JWT puede no ser lo suficientemente flexible.

Idea principal: JWT es una herramienta para sistemas escalables, APIs y frontend modernos, arquitecturas distribuidas, pero no es una solución universal.

Conclusión

JWT token es un método moderno de autorización que permite trabajar sin almacenar sesiones en el servidor. Contiene toda la información necesaria y se verifica mediante una firma, haciendo el sistema rápido y escalable.

En este artículo hemos analizado:

• qué es un JWT token y cómo funciona
• cómo se realiza la autorización sin sesiones
• en qué se diferencia JWT de las sesiones clásicas
• cómo funcionan los access y refresh tokens
• cuáles son los riesgos y cómo evitarlos

En la práctica, JWT es excelente para APIs, apps móviles y microservicios, pero en proyectos simples puede ser excesivo.

En resumen: JWT es comodidad y escalabilidad; las sesiones, control y simplicidad. La elección depende de las necesidades, la arquitectura y los requisitos de seguridad.