Saltar al contenido

¿Qué es JWT o  Web Token JSON?

Cuando desarrollamos aplicaciones web, en muchas ocasiones necesitamos acceder a información externa. Muchas veces de proveedores ajenos a nosotros. Una de las maneras de hacerlo y a la vez hacerlo de forma estandarizada, es mediante JWT.

En realidad, lo que nunca querremos es que cada proveedor de información nos la facilite de una forma diferente y tengamos que leernos toneladas de documentación para entender de que forma solicitársela y obtenerla. Y si se implementa seguridad y permisos de acceso, se complica todo mucho más.

Los estándares al rescate

JSON Web Token (JWT) es un estándar abierto (RFC 7519) que define una forma compacta y autónoma para la transmisión segura de información entre partes como un objeto JSON. Esta información puede ser verificada y confiable porque está firmada digitalmente.

Dicho de otra forma más sencilla, es una forma de intercambiar información en formato JSON pero a la vez, haciéndolo de forma segura. O sea, que solo se intercambiará esa información previo intercambio de claves para verificar si se tiene permiso para ello.

A pesar de que los JWTs pueden ser encriptados para proporcionar confidencialidad entre las partes, me voy a centrar en los tokens firmados.

La diferencia entre estas dos formas es que los tokens firmados pueden verificar la integridad de las peticiones contenidas en ellos, mientras que los tokens encriptados esconden esas peticiones de terceras partes.

Cuando los tokens se firman utilizando pares de claves públicas/privadas, la firma también certifica que sólo la parte que posee la clave privada es la que la firmó.

¿Cuándo se deben utilizar los Web Tokens de JSON?

He aquí algunos escenarios en los que los Web Tokens de JSON son útiles:

Autorización: Éste es el escenario más común para utilizar 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.

Single Sign On es una característica que utiliza ampliamente JWT hoy en día debido a su pequeña sobrecarga y su capacidad de ser utilizado fácilmente en diferentes dominios.

Para el Intercambio de información: Los Web Tokens de JSON son una buena manera de transmitir información entre partes de forma segura. Dado que los JWT pueden firmarse, se puede estar seguro de que los remitentes son quienes dicen ser. Además, como la firma se calcula usando el encabezado y el playload, también se puede verificar que el contenido no ha sido alterado.

¿Cuál es la estructura del Web Token de JSON?

En su forma compacta, los Web Tokens JSON constan de tres partes separadas por puntos (.), que son:

  • Cabecera
  • Playload
  • Firma

Un JWT tiene el siguiente aspecto.

xxxxx.yyyyyy.zzzzzz

Desglosemos las diferentes partes.

Cabecera

El encabezado consta normalmente de dos partes: el tipo de token, que es y el algoritmo de hash que se utiliza, como HMAC SHA256 o RSA.

Por ejemplo:

{“alg”: “HS256”,

“typ”: “JWT”}

Este JSON está codificado en Base64Url para formar la primera parte del JWT.

Playload

La segunda parte es el playload (el cuerpo del mensaje), que contiene las reclamaciones. Los reclamos son declaraciones sobre una entidad (típicamente, el usuario) y datos adicionales. Hay tres tipos de reclamaciones: reclamaciones registradas, públicas y privadas.

Reclamaciones registradas: Se trata de un conjunto de reivindicaciones predefinidas que no son obligatorias pero que se recomiendan, para proporcionar un conjunto de reivindicaciones útiles e interoperables. Algunos de ellos son: iss (emisor), exp (tiempo de expiración), sub (asunto), aud (audiencia), y otros.

Ten en cuenta que los nombres de las reivindicaciones son sólo tres caracteres, ya que JWT está diseñado para ser compacto.

Reclamaciones públicas: Éstos pueden ser definidos a voluntad por aquellos que utilizan JWTs. Pero para evitar colisiones, deben definirse en el Registro de tokens de IANA JSON o definirse como un URI que contenga un espacio de nombres resistente a colisiones.

Reclamaciones privadas: Estos son los reclamos creados para compartir información entre las partes que están de acuerdo en usarlos y que no son reclamos registrados o públicos.

Un ejemplo de playload podría ser:

{  “sub”: “1234567890”,  “name”: “Daniel Mardomingo”,  “admin”: true}

El playload está codificado en Base64Url y es la segunda parte del JSON Web Token.

Ten en cuenta que en el caso de los tokens firmados, esta información, aunque está protegida contra manipulaciones, puede ser leída por cualquier persona. No pongas información sensible en el playload o en los elementos de encabezado de un JWT a menos que esté encriptada.

Firma

Para crear la parte de la firma hay que tomar la cabecera codificada, el playload codificado, un secreto, el algoritmo especificado en la cabecera, y firmarlo.

Por ejemplo, si deseamos 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 mensaje no ha sido cambiado durante el proceso y, en el caso de los tokens firmados con una clave privada, también puede verificar que el remitente del JWT es quien dice ser.

En resumen

¿Mucho lio? ¿No te enteras de nada?

A ver si con todo ello junto la cosa queda más clara.

Hemos visto que la salida son tres cadenas 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 estándares basados en XML como SAML.

A continuación se muestra un JWT que tiene codificada la cabecera y el playload, y está firmado con un secreto.


eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Tenemos la web https://jwt.io/ para ayudarnos en las tareas de codificación decodificación de JWT.

¿Cómo funcionan los Web Tokens de JSON?

En la autenticación, cuando el usuario inicia sesión con éxito utilizando sus credenciales, se devuelve un Web Token JSON. Dado que los tokens son credenciales, se debe tener mucho cuidado para evitar problemas de seguridad. En general, no debemos guardar los tokens más tiempo del necesario.

Siempre que el usuario desee acceder a una ruta o recurso protegido, el agente de usuario debe enviar el JWT, normalmente en la cabecera de autorización utilizando el esquema Portador. El contenido del encabezado debe tener el siguiente aspecto:

Authorization: Bearer <token>

Las rutas protegidas del servidor comprobarán si hay un JWT válido en el encabezado de Autorización, y si está presente, el usuario podrá acceder a los recursos protegidos.

Si el token se envía en el encabezado de Autorización, el Intercambio de Recursos de Origen Cruzado (CORS) no será un problema ya que no utiliza cookies.

Los 3 pasos de un Web Token JSON

  1. La aplicación o el cliente solicita autorización al servidor de autorización. Esto se realiza mediante uno de las diferentes formas de autorización. Por ejemplo, una aplicación web típica compatible con OpenID Connect pasará por el endpoint /oauth/authorize utilizando por ejemplo un usuario y contraseña.
  2. Cuando se concede la autorización, el servidor de autorización devuelve el token de acceso.
  3. La aplicación cliente utiliza el token de acceso para acceder a los recursos protegidos, por ejemplo, una API.

Ten en cuenta que con los tokens firmados, toda la información contenida en el token está expuesta a los usuarios u otras partes, aunque no puedan cambiarla. Esto significa, como dijimos antes, que no debemos poner información secreta dentro del token.

Bueno, espero que con esta introducción te haya quedado un poco más claro como funciona JWT. Por mi parte, los utilizo muy a menudo en los proyectos para los clientes. Ya sea para acceder a APIs así como forma de autenticación en servicios como Firebase.

Download WordPress Themes
Free Download WordPress Themes
Download Best WordPress Themes Free Download
Download Nulled WordPress Themes
free download udemy course