JWT o JSON Web Token es un estándar definido por el RFC 7519, que orienta la manera de transmitir y almacenar objetos JSON entre aplicaciones de forma compacta y segura.

Utilizado tanto para la autenticación como para el intercambio de información, JWT es un estándar que no puede estar lejos del conocimiento de un buen desarrollador.

En este contenido, hablaremos más sobre JWT y mostraremos cómo está formada su estructura. ¡Buena lectura!

¿Quién es JWT?

Este es un estándar muy conocido que forma parte de una gran familia, la cual tiene a JOSE (JSON Object Signing and Encryption) como su “padre”.

El JOSE está formado por las siguientes especificaciones:

• JWT (JSON Web Token), que es el propio Token;
• JWS (JSON Web Signature), que representa la firma del Token;
• JWE (JSON Web Encryption), consistente en la encriptación para la firma del Token;
• JWK (JSON Web Keys), que son las claves para la firma;
• JWA (JSON Web Algorithms), que representa los algoritmos para la firma del Token.

El JWT es más famoso entre estas especificaciones, porque es por medio de él que se utilizan las demás.

Este estándar se describe como una forma compacta y segura de representar las Claims, que son las reivindicaciones entre las partes. JWT la codifica como objetos JSON, que pueden ser firmados digitalmente o encriptados.

Para que esto suceda, se utilizan el JWS y el JWE, que a su vez proporcionarán muchos tipos de firmas y encriptaciones.

¿Cuál es la diferencia entre un JWT firmado y uno encriptado?

El primero es firmado usando un secreto, como el algoritmo HMAC, o un par de claves públicas/privadas, usando RSA o ECDSA. Este tipo comprueba la integridad de las afirmaciones contenidas en él.

El JWT encriptado también garantiza el secreto de la información entre las partes.

¿Por qué JWT ha sido tan utilizado?

Una de las razones es que utiliza JSON, un estándar conocido por ser amigable y fácil de entender. Es simple de manipular en cualquier lenguaje y ligero para ser transportado a través de la red.

JWT también se destaca por la seguridad de la información que contiene, ya que es posible comprobar si el contenido del Token es válido por medio de su propio contenido. Esto puede parecer algo raro en un primer momento, pero cuando mostramos la estructura del JWT, la comprensión se hará más clara.

¿Dónde se usa el JWT?

Hay tres momentos en los que se destaca:

• Autenticación, principalmente por la facilidad de uso entre los diferentes dominios;
• Autorización, una vez que el usuario se conecta, cada solicitud realizada al servidor incluirá un JWT, permitiendo su acceso a las rutas, servicios y recursos que fueron liberados a través del Token;
• Intercambio de información, ya que decimos que el JWT es una forma segura de realizar este proceso entre las partes.

¿Cuál es la estructura de un JWT?

A continuación, fíjate en un ejemplo de un JWT:

Para una persona no experta en el tema, puede parecer como algo complejo. Pero hay que recordar que es una compresión de una serie de Claims unidas a una firma que garantiza su autenticidad.

Para hacerlo, es dividido en tres partes, cada una de las cuales separada por un punto (.):

1. Header

Se trata de un objeto JSON que básicamente define el tipo de Token y cuál es el algoritmo de encriptación que se utiliza en su firma, que puede ser HMAC, SHA256 o RCA.

El JSON que está abajo será codificado usando el método Base64Url, convirtiéndolo en la primera secuencia del JWT.

Es posible combinar un JWT haciendo que la payload contenga otro JWT. En estos casos, el header también tendrá una especificación para definir el tipo de contenido, quedándose de la siguiente manera:

2. Payload

El segundo bloque, que también es objeto de JSON, es el layload, donde se contienen las Claims, consideradas una parte importante del JWT. Algunas de estas reivindicaciones tienen un significado propio de la especificación JWT, mientras que otras pueden ser definidas por el usuario.

Hay tres tipos de Claims. La principal es “Registered”, que son las reivindicaciones predefinidas por la norma del JWT. Su uso no es obligatorio, pero se recomiendan algunos.

Estas Claims tienen información muy útil y fácilmente identificable, como:

• Sub, de subject, entidad a la que pertenece el JWT;
• Iat, de issued at, que representa un timestamp – información de fecha y hora cuando el JWT fue usado;
• Exp, de expiration, que identifica el tiempo de uso del Token, es decir, su expiración.

Las Claims que no formen parte de la lista “Registered” son las reivindicaciones creadas por los usuarios y deben ser Public o Private.

En la creación de una Claim, se debe tener el cuidado de no provocar una colisión de nombres, porque es ahí donde surge la diferenciación entre ellos.

Las Public Claims deben ser definidas en el IANA JSON Web Token Registry, o ser definidas a través de un URL que contenga un namespace.

Las Privates Claims son definidas únicamente entre las partes que las utilizarán, y ambas deben ser conscientes de que serán privadas.

Una curiosidad: En el caso de una Claim duplicada, la lectura se hace como la de un JSON normal, valiendo el último valor asignado a esa clave.

3. Signature

Este es el tercer bloque de un JWT y está formado por el encode del Header, el encode del Payload y una contraseña. Todo esto está debidamente codificado en el formato que se especificó en el encabezado.

Comprueba un código de ejemplo, donde se utilizó el HMACSHA256 para codificar toda la información, y este patrón fue especificado en el Header:

Finalmente, ¡el JWT está formado!

¿Vale la pena usar el JWT?

JWT es un estándar aceptado por muchos lenguajes y casi ningún desarrollador encontrará barreras para la disponibilidad de la biblioteca.

Por lo tanto, no es de extrañar que el JWT haya ido ganando cada vez más protagonismo en el desarrollo de aplicaciones, ya que es compacto y fácil de decodificar y comprender. Todavía tiene la ventaja de poder ser comprobado y encriptado.

Es importante destacar que el JWT tiene algunos competidores, como el SWT (Simple Web Tokens). Sin embargo, este no tiene la misma eficacia, porque utiliza una llave compartida entre las partes.

Otro competidor conocido es SAML (Security Assertion Markup Language Tokens), que utiliza el estándar XML en lugar de JSON; lo que lo deja un poco anticuado.