Introducción a los tokens web JSON

El token web JSON (JWT) es un estándar abierto (RFC 7519) que define un método compacto y autocontenido para la transmisión segura de información entre partes codificadas como un objeto JSON. Esta información puede verificarse y ser fiable porque está firmada digitalmente. Los JWT pueden firmarse utilizando un secreto (con el algoritmo HMAC) o un par de claves públicas/privadas utilizando RSA.

Expliquemos mejor algunos conceptos de esta definición.

• Compacto: Debido a su tamaño, puede enviarse a través de una URL, un parámetro POST o dentro de un encabezado HTTP. Además, debido a su tamaño, su transmisión es rápida.
• Autónomo: La carga útil contiene toda la información necesaria sobre el usuario, para evitar consultar la base de datos más de una vez.

Estos son algunas situaciones en las que los tokens web JSON son útiles:

• Autenticación: Esta es la situación típica para el uso de JWT, una vez que el usuario ha iniciado sesión, cada solicitud posterior incluirá el JWT, permitiendo al usuario acceder a las rutas, servicios y recursos que están permitidos con ese token. El inicio de sesión único es una característica que utiliza ampliamente JWT hoy en día, debido a su pequeña sobrecarga y su capacidad para ser utilizado fácilmente entre los sistemas de diferentes dominios.
• Intercambio de información: Los JWT son una buena forma de transmitir información de forma segura entre las partes, porque como se pueden firmar, por ejemplo utilizando un par de claves públicas/privadas, se puede estar seguro de que el remitente es quien dice ser. Además, como la firma se calcula utilizando el encabezado y la carga útil, también puedes verificar que el contenido no ha cambiado.

Los JWT constan de tres partes separadas por puntos (.), que son las siguientes:

• Encabezado
• Carga útil
• Firma

Por lo tanto, un JWT suele tener el siguiente aspecto.

xxxxx.yyyyy.zzzzz

Desglosemos las distintas partes.

Encabezado

El encabezado suele constar de dos partes: el tipo de token, que es JWT, y el algoritmo de hash, como HMAC SHA256 o RSA.

Por ejemplo:

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

A continuación, este JSON se codifica con Base64Url para formar la primera parte del JWT.

Carga útil

La segunda parte del token es la carga útil, que contiene las reclamaciones. Las reclamaciones son declaraciones sobre una entidad (normalmente, el usuario) y metadatos adicionales. Existen tres tipos de reclamaciones: reservadas, públicas y privadas.

• • Reclamaciones reservadas: Se trata de un conjunto de reivindicaciones predefinidas, no obligatorias sino recomendadas, pensadas para ofrecer un conjunto de reivindicaciones útiles e interoperables. Algunas de ellas son iss (emisor), exp (tiempo de caducidad), sub (sujeto), aud (audiencia), entre otros.

Observa que los nombres de las reclamaciones solo tienen tres caracteres, ya que JWT está pensado para ser compacto.

• Reclamaciones públicas: Estas pueden ser definidas a voluntad por aquellos que utilizan JWT. Pero para evitar colisiones, deben definirse en el Registro de tokens web JSON de la IANA o definirse como una URI que contenga un espacio de nombres resistente a las colisiones.
• Reclamaciones privadas: Son las reclamaciones personalizadas creadas para compartir información entre las partes que acuerdan utilizarlas.

Un ejemplo de carga útil podría ser el siguiente:

{
  'sub': '1234567890',
  'name': 'John Doe',
  'admin': true
}

A continuación, la carga útil se codifica con Base64Url para formar la segunda parte del JWT.

Firma

Para crear la parte de la firma hay que tomar el encabezado codificado, la carga útil codificada, un secreto, el algoritmo especificado en el encabezado y firmarlo.

Por ejemplo, si deseas utilizar el algoritmo HMAC SHA256, la firma se creará de la siguiente manera.

HMACSHA256(
  base64UrlEncode(header) + '.' +
  base64UrlEncode(payload),
  secret)

La firma se utiliza para verificar que el remitente del JWT es quien dice ser y para garantizar que el mensaje no ha sufrido ninguna modificación.

Ponerlo todo junto

La salida son tres cadenas Base64 separadas por puntos que se pueden pasar fácilmente en entornos HTML y HTTP, a la vez que son más compactas en comparación con los estándares basados en XML como SAML.

A continuación, se muestra un JWT que tiene el encabezado y la carga útil anteriores codificadas y está firmado con un secreto.

Puedes navegar a jwt.io, donde podrás jugar con un JWT y poner en práctica estos conceptos. jwt.io te permite decodificar, verificar y generar JWT.

En la autenticación, cuando el usuario inicia sesión con éxito utilizando sus credenciales, se devolverá un token web JSON. Dado que los tokens son credenciales, hay que tener mucho cuidado para evitar problemas de seguridad. En general, no debes conservar los tokens más tiempo del necesario.

Tampoco debe almacenar datos de sesión confidenciales en el almacenamiento del navegador debido a la falta de seguridad.

Siempre que el usuario quiera acceder a una ruta protegida, deberá enviar el JWT, normalmente en el encabezado de Autorización utilizando el esquema Bearer. Por lo tanto, el contenido del encabezado debe tener el siguiente aspecto.

Autorización: Bearer <token>

Se trata de un mecanismo de autenticación sin estado, ya que el estado del usuario nunca se guarda en la memoria del servidor. Las rutas protegidas del servidor comprobarán si hay un JWT válido en el encabezado de Autorización, y si lo hay, se permitirá al usuario. Como los JWT son autónomos, toda la información necesaria está ahí, lo que reduce la necesidad de ir y venir a la base de datos.

Esto permite confiar plenamente en las API de datos sin estado e incluso realizar solicitudes a servicios posteriores. No importa qué dominios estén sirviendo tus API, ya que Cross-Origin Resource Sharing (CORS) no será un problema porque no utiliza cookies.

Hablemos de las ventajas de los tokens web JSON (JWT) comparándolos con los tokens web simples (SWT) y los tokens de lenguaje de marcado de aserción de seguridad (SAML).

Como JSON es menos verboso que XML, cuando se codifica, su tamaño también es menor; lo que hace que JWT sea más compacto que SAML. Esto hace que JWT sea una buena opción para pasar en entornos HTML y HTTP.

Desde el punto de vista de la seguridad, SWT solo puede firmarse simétricamente mediante un secreto compartido utilizando el algoritmo HMAC. Mientras que los tokens JWT y SAML también pueden utilizar un par de claves públicas/privadas en forma de certificado X.509 para firmarlos. Sin embargo, firmar XML con XML Digital Signature sin introducir agujeros de seguridad oscuros es muy difícil comparado con la simplicidad de firmar JSON.

Los analizadores JSON son comunes en la mayoría de los lenguajes de programación, porque mapean directamente a objetos, por el contrario XML no tiene un mapeo natural de documento a objeto. Esto hace que sea más fácil trabajar con JWT que con las aserciones SAML.

En cuanto al uso, JWT se utiliza a escala de Internet. Esto pone de relieve la facilidad de procesamiento de JWT por parte del cliente en múltiples plataformas, especialmente móviles.

En Auth0, emitimos JWT como resultado del proceso de autenticación. Cuando el usuario inicia sesión utilizando Auth0, se crea un JWT, se firma y se envía al usuario. Auth0 soporta la firma JWT tanto con algoritmos HMAC como RSA. A continuación, este token se utilizará para autenticarse y autorizarse con las API, que concederán acceso a sus rutas y recursos protegidos.

También utilizamos JWT para realizar la autenticación y autorización en la API v2 de Auth0, reemplazando el uso tradicional de claves API opacas regulares. En cuanto a la autorización, los tokens web JSON permiten una seguridad granular, es decir, la posibilidad de especificar un conjunto concreto de permisos en el token, lo que mejora la depurabilidad.