Un JSON Web Token (JWT) es una entidad abstracta que permite transmitir información entre sistemas de forma verificable, y entender su estructura es clave para cualquier desarrollador que trabaje con autenticación en la web. Aquí descubrirás cómo se compone, qué son los claims y por qué la firma garantiza su integridad.

¿Qué es un JSON Web Token y por qué no existe por sí solo?

Un JWT por sí mismo no es nada concreto: es una abstracción que cobra vida cuando se implementa. Puede materializarse como JSON Web Encryption (cuando el contenido se encripta) o como JSON Web Signature (cuando se firma). En la web, lo que vas a encontrar la gran mayoría del tiempo son JSON Web Signature.

¿Qué es un JWT en términos simples? Es un estándar para transmitir información firmada o encriptada entre dos partes en formato JSON, garantizando que nadie alteró el contenido por el camino.

¿Cómo se ve un JWT en serialización compacta?

El formato más común es la serialización compacta, que se compone de tres partes separadas por puntos:

• El encabezado, codificado en base 64.
• El payload, también codificado en base 64.
• La firma, generada a partir de los dos anteriores.

Si tomas un token y lo pegas en un servicio como jwt.io, vas a poder leer el encabezado y el payload sin problema, además del algoritmo usado para firmarlo. Por eso nunca debes poner información sensible ahí adentro.

¿Qué son los claims y cuántos tipos existen?

Los claim names son la forma estandarizada de compartir información dentro del payload. Existen tres tipos y conocerlos te ayuda a diseñar tokens consistentes y compatibles con otros sistemas.

Los registered claims son siete en total y, aunque no son obligatorios, se recomiendan para garantizar interoperabilidad entre aplicaciones. Los cuatro más importantes son:

• Issuer: identifica al authorization server que emitió el token.
• Subject: contiene el ID del usuario o resource owner.
• Audience: indica el destinatario del token, normalmente el resource server o API que vas a consumir.
• Tiempo de expiración: define cuándo deja de ser válido el token, y conviene mantenerlo corto.

Los public claims son nombres comunes como el nombre o el correo electrónico, y se recomienda registrarlos ante la IANA (Internet Assigned Numbers Authority) para evitar colisiones con otros sistemas.

Los private claims son específicos de tu aplicación: el ID del empleado, el área a la que pertenece o cualquier dato relevante solo para tu negocio.

¿Cómo se ve un payload con los tres tipos de claims?

Un payload completo combinaría algo como un subject y un tiempo de expiración (registered), un nombre y correo (public), y un app ID con una referencia interna (private). Esa mezcla te da flexibilidad sin romper el estándar.

¿Cómo funciona el algoritmo de firmado de un JWT?

Aquí está la verdadera magia. El proceso es directo: tomas el encabezado codificado en base 64, lo concatenas con un punto y el payload también en base 64, y aplicas el algoritmo de firmado usando un secreto o una llave. El resultado es la firma, que se anexa al final.

Y aquí viene lo interesante: como el payload se puede decodificar, alguien podría modificarlo, volver a codificarlo y armar un token alterado. Literalmente puedes hacerlo. Pero ese token no va a funcionar, porque al verificarlo, el authorization server repite el proceso de firmado con su llave y se da cuenta de que la firma generada no coincide con la firma entregada.

¿Por qué no puedo modificar un JWT y usarlo? Porque la firma se genera a partir del encabezado y el payload originales. Si cambias cualquier cosa, la firma deja de coincidir y el servidor lo rechaza.

Por eso se llama firma: igual que cuando firmas un documento físico, demuestra que el contenido es legítimo y no fue manipulado.

¿Cuál es la diferencia entre firmado simétrico y asimétrico?

Existen múltiples algoritmos, y los más populares se dividen en dos familias:

• RS256 (asimétrico): usa una llave privada para firmar y una llave pública para verificar. La llave privada solo la conoce el authorization server; la pública puede distribuirse libremente al cliente.
• HS256 (simétrico): usa la misma llave privada tanto para firmar como para verificar. Esto significa que solo sistemas seguros con acceso a esa llave pueden validar el token.

La elección depende de tu arquitectura: si necesitas que múltiples servicios verifiquen tokens sin compartir secretos, el asimétrico es tu camino.

¿Cómo identificar un JWT en aplicaciones reales?

Te propongo un reto. Abre las herramientas de desarrollo de tu navegador y revisa las cookies, el local storage o el session storage de los servicios que usas a diario. Si encuentras una cadena dividida en tres partes separadas por dos puntos, muy probablemente sea un JWT en serialización compacta.

Extráelo, pégalo en jwt.io y observa qué hay en el encabezado y el payload. Vas a aprender mucho sobre cómo las aplicaciones manejan tu sesión. Eso sí, nunca compartas el token completo en foros o comentarios, porque cualquiera podría usarlo para acceder a tu información. Comparte solo lo que descubriste.

¿Qué encontraste al inspeccionar tus servicios favoritos? Cuéntame en los comentarios qué claims descubriste y qué algoritmos están usando.