JWT Explicado: El estándar moderno de autenticación y cómo sobrevivíamos antes de él

Bienvenidos de nuevo a Code With Botina. Si has estado construyendo APIs o aplicaciones modernas, seguramente te has topado con el gran dilema: "¿Cómo sé de forma segura quién es el usuario que me está haciendo esta petición?".

Hoy vamos a desmitificar una de las tecnologías más usadas (y a veces peor entendidas) en la arquitectura web: los JWT (JSON Web Tokens). Vamos a ver qué son, cómo se usan en la vida real y cómo era el oscuro mundo de la autenticación antes de que existieran.

---

El Pasado: ¿Cómo nos autenticábamos antes de JWT? (Sesiones con Estado)

Para entender por qué JWT es tan popular, primero debemos entender el problema que vino a resolver. Antes, el rey indiscutible era la Autenticación Basada en Sesiones (Stateful).

Funcionaba así:

1. Iniciabas sesión con tu usuario y contraseña.
2. El servidor verificaba tus datos y creaba un registro en su propia memoria (o base de datos) diciendo: "El ID de sesión abc-123 pertenece a Zeus".
3. El servidor te devolvía ese ID (abc-123) guardado en una Cookie.
4. En cada petición futura, tu navegador enviaba esa Cookie. El servidor tenía que buscar en su memoria: "A ver, ¿quién era el dueño de abc-123? Ah, sí, Zeus. Déjalo pasar".

¿Cuál era el problema? La Escalabilidad. Si tu aplicación crecía y necesitabas tener 5 servidores (Microservicios), ¡el servidor número 2 no sabía quién eras porque tu sesión estaba guardada en la memoria del servidor 1! Tenías que implementar bases de datos compartidas solo para sesiones (como Redis), lo cual añadía mucha complejidad y latencia.

---

El Presente: ¿Qué es un JWT? (Autenticación Sin Estado)

JWT (se pronuncia "jot") significa JSON Web Token. Es un estándar abierto que permite transmitir información entre dos partes de forma segura como un objeto JSON.

La magia del JWT es que es Stateless (Sin Estado). El servidor ya no necesita guardar nada en su memoria para saber quién eres. Toda la información necesaria viaja dentro del propio token.

Un JWT parece una cadena de texto sin sentido, pero en realidad está compuesto por tres partes separadas por puntos (.):

1. Header (Cabecera): Dice qué tipo de token es y qué algoritmo se usó para firmarlo.
2. Payload (Carga útil): Aquí van tus datos (llamados claims). Por ejemplo: tu ID de usuario, tu rol (admin o usuario), y cuándo expira el token.
3. Signature (Firma): Es la parte más importante. El servidor toma el Header, el Payload y una Clave Secreta que solo él conoce, y genera una firma criptográfica.

Si un hacker intenta cambiar su rol de "usuario" a "admin" en el Payload, la firma ya no coincidirá matemáticamente y el servidor rechazará el token instantáneamente.

---

¿Cómo se utiliza un JWT en la vida práctica?

Los JWT se usan principalmente para la Autenticación en APIs. Así es el flujo moderno cuando inicias sesión en una SPA (Single Page Application) o desde tu teléfono:

1. El Inicio de Sesión (Login): Ingresas tu usuario y contraseña. El servidor verifica en la base de datos que eres tú.
2. La Creación del Token: El servidor toma tus datos básicos (tu ID, tu correo, cuándo expira la sesión) y los firma con su clave secreta creando un JWT.
3. El Token viaja al Cliente: El servidor te devuelve ese token como un "pase de abordar" digital.
4. Almacenamiento en el Cliente: Tu navegador o aplicación móvil guarda ese token (usualmente en localStorage, o idealmente en una HTTPOnly Cookie por seguridad).
5. Las Peticiones Futuras: En cada petición (por ejemplo, ver tu perfil o comprar algo), el cliente envía este token al servidor, normalmente en la cabecera de la petición llamada Authorization: Bearer .
6. La Verificación (Sin Base de Datos): El servidor recibe el token y con su clave secreta verifica matemáticamente la firma del JWT. No necesita consultar ninguna base de datos para saber quién eres ni tu rol. Sabe todo lo que necesita solo con leer la carga útil.

---

Conclusión

JWT nos ha salvado de la pesadilla de sincronizar servidores y crear bases de datos gigantescas solo para recordar quién estaba conectado. Su naturaleza "Sin Estado" lo hace perfecto para arquitecturas de Microservicios, APIs REST y Serverless.

Pero ten cuidado: Los JWT están codificados, no encriptados. ¡Cualquiera puede leer el Payload de un token! NUNCA pongas información sensible como contraseñas en el payload de tu token.

¿Ya has implementado JWT en tus proyectos o sigues usando sesiones con estado? ¡Cuéntame en los comentarios!

---

Suscríbete a Code With Botina para seguir escalando tus conocimientos de backend, APIs y seguridad.