JWT explained!! Al fin!!!

Siguiendo con la onda de seguridad, autenticación y autorización, hoy vamos a hablar de uno de los elementos que ya hemos mencionado como parte de estos mecanismos, los ya famosos Json Web Token o JWT, el cual es un String que cumple con el estándar RFC 7519 para transmitir información con la identidad y claims de un usuario de forma segura entre un cliente/servidor. Dicha información puede ser verificada y confiable porque está firmada digitalmente.

En otras palabras, JWT es un contenedor o cadena de caracteres codificados en BASE64 y separados por un punto. Cada parte del JWT corresponde al Header, Payload y Signature respectivamente.

Estructura

Un JSON Web Token está dividido en tres partes .

1. La primera es el HEADER, se denomina JOSE o JavaScript Object Signing and Encryption y define cual es la tecnología criptográfica que se va a aplicar al token para securizar la información.
2. La segunda parte  es el PAYLOAD, cuerpo o también conocido como JWT PayLoad o JWT Claims y almacena la información de negocio que necesitamos en el token. Esta parte se puede estructurar de muchas formas.
3. La tercera parte es el SIGNATURE, o la firma JWT que se encarga de dar validez al token.

Es importante aclarar que la cadena/token esta codificado y lo crea nuestra aplicación, esto nos permite de manera muy fácil inspeccionar su contenido, por ejemplo con: JWT Debugger.

Ejemplo de un JWT:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.VuLOt6gBoBkdEcIIuZmQPrRachKywobaXML5Ttgf3G4

Al inspeccionar nuestro JWT de ejemplo en la dirección  https://jwt.io podemos ver lo siguiente:

Pasemos ahora a estudiar cada parte por separado, así que manos a las sobras...

Header

Como ya hemos especificado, el primer elemento es el HEADER o JOSE.

Encoded:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Decoded:

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

Aquí vemos cómo definimos el tipo de token y el algoritmo criptográfico que vamos a utilizar (HS256). ¿Esto que quiere decir exactamente? . En nuestro caso quiere decir que estamos usando un token JWT y un algoritmo de HASH muy concreto denominado HMAC que genera un hash con SHA256 utilizando una clave privada. Ya abordaremos estos conceptos en detalle más adelante.

Payload

Este es el cuerpo del mensaje en el que podemos definir la información de negocio que consideremos adecuada.

Encoded:
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

Decoded:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Signature

La tercera parte  del token

Encoded:
VuLOt6gBoBkdEcIIuZmQPrRachKywobaXML5Ttgf3G4

Simplemente es un hash con la siguiente estructura:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  CLAVE_PRIVADA)

CLAVE_PRIVADA del ejemplo es "secreta".

Criptografía y JSON Web Token

Para entender JWT necesitamos repasar algunos de conceptos criptográficos . Lo primero que tenemos que entender es el concepto de algoritmo de HASH. Un algoritmo de HASH se encarga de generar un HASH (bloque de caracteres de longitud fija) a partir de una cadena arbitraria de texto.

Los algoritmos de hash sirven para comprobar que en ningún momento se ha modificado el texto original ya que se aseguran de que ante dos textos distintos siempre se genera un hash diferente. Por lo tanto si alguien nos cambia el texto original y lo intenta dar por válido podemos regenerar el hash y comprobar si cumple.

JSON Web Token y HMAC

¿Qué es lo que tiene en especial usar un algoritmo HMAC para generar el hash?. Lo que tiene de especial es que este algoritmo criptográfico se encarga de generar un hash para un texto utilizando una clave privada.

Esto implica una diferencia importante ya que los HASH solo los pueden generar aquellas personas que conozcan la clave privada. Por lo tanto no solo sabemos ahora que el contenido no ha sido modificado sino también podemos saber quien es su creador. Vamos a profundizar un poco mas con este diagrama:

El diagrama explica cómo se genera el HASH

1. En primer lugar generamos las estructuras de base64 tanto de la parte JOSE como de los Claims
2. En segundo lugar usaremos el algoritmo HMAC con su clave privada para generar un HASH basado en las estructuras de Base64.

Realizadas ambas operaciones el último paso es sumarlo todo y generar un token:

Este token será el que enviemos al cliente y le permitirá autenticarse más adelante.

JWT y Servidor

La forma de procesar los tokens JWT está ligada al servidor pero básicamente es algo del estilo:

1. El cliente se logea en el servidor y envía usuario y clave
2. El sistema le valida y genera un token usando el algoritmo HMAC y la clave privada
3. El cliente recibe el token
4. El cliente solicita unos datos y pasa como identificador el token
5. El servidor decodifica los bloques de base64 y usa su clave privada para comprobar el HASH. Si todo es correcto, permite el acceso y envía la información solicitada al cliente.

Podemos observar hasta aquí, porque JWT es tan popular como mecanismo de autorización para APIs.