Token web JSON: JWT

JWT (JSON Web Token ) es un formato de token de seguridad, definido por un estándar abierto ( RFC 7519 ). Proporciona una solución al problema de pasar reclamaciones entre partes. Es un estándar de la industria para tokens de seguridad utilizados para transmitir información de forma segura entre el cliente y el servidor como objetos JSON. Como formato de token, define un mecanismo compacto y autónomo para transmitir datos entre partes de una manera que se pueda verificar y confiar porque está firmado digitalmente. JWT no utiliza cookies y se puede utilizar en varios dominios. Además, las reglas de codificación de un JWT también hacen que estos tokens sean bastante fáciles de usar dentro del contexto de HTTP. Como está firmado digitalmente, esta información se puede verificar y confiar. Los JWT se pueden firmar utilizando un secreto (con el algoritmo HMAC) o un par de claves pública/privada utilizando RSA.

Las dos propiedades principales de esta norma son:

Compacto: un token JWT es autónomo, pequeño y completo. Debido a que son muy compactos, los JWT se pueden enviar a través de una URL, un parámetro POST o dentro de un encabezado HTTP. Sin embargo, el tamaño de la carga útil puede aumentar según la cantidad de información que contenga el token.

Autónomo: un token JWT es autónomo y contiene toda la información de identificación necesaria. Son una excelente opción para implementar mecanismos de autenticación sin estado sin utilizar sesiones, ya que todo lo necesario está en la carga útil del token. El uso de tokens JWT como mecanismo de autenticación significa que lo único que una parte debe presentar para obtener acceso a un recurso protegido es el token en sí; el token en cuestión puede denominarse token portador.

Estructura de un JWT

Un token JWT tiene tres partes: encabezado, carga útil y firma, como se muestra a continuación.

Encabezamiento

La parte del encabezado decide qué algoritmo se debe utilizar para generar el token. El encabezado tiene información que se requiere en el backend para reconocer qué operación criptográfica se debe realizar en función de esa información (metadatos, algoritmos y claves que se utilizan):

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

Carga útil

La segunda parte consiste en una carga útil proporcionada en formato JSON. La carga útil contiene reclamaciones. Una reclamación es un fragmento de información que el cliente envía al servidor y que debe ser autenticado. Lo más común es que sea el nombre de usuario, pero puede incluir cualquier conjunto de datos. Las reclamaciones pueden ser reclamaciones registradas, reclamaciones públicas o reclamaciones privadas. Las reclamaciones registradas están definidas por la especificación JWT. Estas reclamaciones tienen una clave y un propósito ya definidos. Estas reclamaciones se enumeran en la especificación aquí .

Algunos ejemplos de reclamaciones registradas son:

• Emisor ( iss ): Esto nos permite saber quién ha emitido el token.
• Audiencia ( aud ): Esto nos permite saber que este token debe ser consumido por nuestra aplicación.
• Asunto ( sub ): Esto nos permite saber qué parte de la aplicación puede usar el token (útil en aplicaciones más grandes).
• Emitido en ( iat ): Esto nos permite saber cuándo se ha creado el token.
• Fecha de expiración ( exp ): Esto nos permite saber cuándo el token está por expirar, por lo que debemos generar uno nuevo.
• No antes ( nbf ): define el momento antes del cual no se debe aceptar el JWT para su procesamiento.
• ID JWT ( jti ): proporciona un identificador único para el JWT.

Las reclamaciones públicas son claves definidas por usted y deben ser resistentes a colisiones. Por lo general, se definen como un URI con un espacio de nombres para evitar colisiones. Las reclamaciones privadas son reclamaciones personalizadas que dos partes acuerdan usar para compartir información. Las reclamaciones privadas no están registradas ni son públicas.

Esta es una muestra de carga útil

{
    "iss": "thetalentbot.com",
    "jti": "00586f3a-3aa5-46f3-add0-ae62c11919fe",
    "name": "Pradeep Loganathan",
    "iat": 1545698610,
    "exp": 1558893661
}

Firma

La última parte es la firma criptográfica representada por una Firma Web JSON (JWS). Estas se manejan en sus propias especificaciones como Firma Web JSON (JWS) y Cifrado Web JSON (JWE). Una firma permite que un JWT sea validado contra modificaciones. Esto asegura que ningún intruso o intermediario pueda actuar como el usuario solicitante, ya que no podrán firmar la solicitud. El cifrado, por otro lado, asegura que el contenido del JWT solo sea legible por ciertas partes. En el ejemplo anterior (HS256), el algoritmo utilizado para la firma es HMAC SHA-256.

Ahora que tenemos todas las piezas del JWT, podemos componer el JWT como se muestra a continuación.

• El encabezado y las reclamaciones están codificados en base64 para su transporte.
• Luego, el encabezado y las reclamaciones se agregan junto con un carácter de punto para que la carga útil = base64URLencode(headers) + “.” + base64URLencode(claims).
• La firma ahora se genera utilizando el algoritmo mencionado en el encabezado, de modo que la firma = base64URLencode(HMACSHA256(payload, secret));
• Finalmente, el JWT se compone de encodedJWT = payload + “.” + signature

Podemos utilizar una herramienta como el depurador jwt.io para visualizar un token jwt. El token codificado se encuentra a la izquierda y la información decodificada a la derecha.

Flujo de autenticación basado en tokens

Ahora que conocemos la estructura de un JWT, necesitamos comprender el proceso de generar un JWT, presentarlo a un servidor de recursos y autenticarlo.

El esquema de autenticación basado en token se puede dividir en dos partes distintas.

Solicitud de autenticación : la primera parte es la solicitud de autenticación. El cliente proporciona credenciales para identificarse ante el servidor de tokens. El servidor de tokens valida las credenciales y genera un token con las afirmaciones necesarias y lo envía al cliente.

Solicitud de recursos : la segunda parte es la solicitud a un punto final protegido en el servidor de recursos. El cliente proporciona el token adquirido anteriormente al servidor de recursos junto con la solicitud posterior. Este token se proporciona en el encabezado de autorización como un token portador. El servidor de recursos valida el token y, si la validación es exitosa, responde con el recurso solicitado.

Como el JWT es autónomo, el servidor de recursos puede extraer información e incluso datos sobre el sujeto y validar el token de acceso localmente. No necesita utilizar una base de datos compartida ni validar de forma remota con el servidor de tokens. Las reclamaciones en el JWT representadas como carga útil JSON pueden estar firmadas o cifradas con HMAC para garantizar la seguridad.

En la próxima publicación , veremos cómo generar un token JWT usando un microservicios de autenticación.