# JSON Web Token

JSON Web Token (abreviado JWT) es un estándar abierto basado en JSON propuesto por IETF (RFC 7519) para la creación de tokens de acceso que permiten la propagación de identidad y privilegios o claims en inglés. Por ejemplo, un servidor podría generar un token indicando que el usuario tiene privilegios de administrador y proporcionarlo a un cliente. El cliente entonces podría utilizar el token para probar que está actuando como un administrador en el cliente o en otro sistema.  El token está firmado por la clave del servidor, así que el cliente y el servidor son ambos capaces de verificar que el token es legítimo. Los JSON Web Tokens están diseñados para ser compactos, poder ser enviados en las URLs -URL-safe- y ser utilizados en escenarios de Single Sign-On (SSO). Los privilegios de los JSON Web Tokens puede ser utilizados para propagar la identidad de usuarios como parte del proceso de autenticación entre un proveedor de identidad y un proveedor de servicio, o cualquiera otro tipo de privilegios requeridos por procesos empresariales.
El estándar de JWT se basa en otros estándares basados en JSON JSON Web Signature (RFC 7515) y JSON Web Encryption (RFC 7516)

## Estructura

Los JSON Web Tokens generalmente están formados por tres partes: un encabezado o header, un contenido o payload, y una firma o signature. El encabezado identifica qué algoritmo fue usado para generar la firma y normalmente se ve de la siguiente forma:
HS256 indica que este token está firmado utilizando HMAC-SHA256.
El contenido contiene la información de los privilegios o claims del token:
El estándar sugiere incluir una marca temporal o timestamp en inglés, llamado iat para indicar el momento en el que el token fue creado.
La firma está calculada codificando el encabezamiento y el contenido en base64url, concatenándose ambas partes con un punto como separador:
En el token, las tres partes -encabezado, contenido y firma- están concatenadas utilizando puntos de la siguiente forma:
El token puede ser fácilmente transmitido en entornos HTML y HTTP, siendo similar a estándares basados en XML como SAML. Generalmente los algoritmos de cifrado utilizados son HMAC con SHA-256 (HS256) y firma digital con SHA-256 (RS256).

## Uso

La autorización se logra cuando el usuario ingresa sus credenciales con éxito, entonces se genera un JSON Web Token que es retornado al cliente, quien tiene que guardarlo localmente, en vez del modelo tradicional de crear una sesión en el servidor y retornar una cookie.
Siempre que el usuario quiere acceder a una ruta protegida o recurso, el cliente tiene que enviar el JWT, generalmente en el encabezado de Authorization utilizando el esquema Bearer. El contenido del encabezado HTTP se ve de la siguiente forma:
    Authorization: Bearer eyJhbGci...<snip>...yu5CSpyHI
Este es un mecanismo de autenticación sin estado - stateless- ya que la sesión del usuario nunca se guarda en el proveedor de identidad o en el proveedor del servicio. Los recursos protegidos siempre comprobaran si existe un JWT válido en cada pedido de acceso. Si el token está presente y es válido, el proveedor del servicio otorga accesos a los recursos protegidos. Como los JWTs contienen toda la información necesaria en sí mismos, se reduce la necesidad de consultar la base de datos u otras fuentes de información múltiples veces.

## Campos estándares

El estándar define los siguientes campos que pueden incluirse en los tokens JWT:
| Código | Nombre | Descripción |
| iss | Issuer | Identifica el proveedor de identidad que emitió el JWT |
| sub | Subject | Identifica el objeto o usuario en nombre del cual fue emitido el JWT |
| aud | Audience | Identifica la audiencia o receptores para lo que el JWT fue emitido, normalmente el/los servidor/es de recursos (e.g. la API protegida). Cada servicio que recibe un JWT para su validación tiene que controlar la audiencia a la que el JWT está destinado. Si el proveedor del servicio no se encuentra presente en el campo aud, entonces el JWT tiene que ser rechazado |
| exp | Expiration time | Identifica la marca temporal luego de la cual el JWT no tiene que ser aceptado. |
| nbf | Not before | Identifica la marca temporal en que el JWT comienza a ser válido. EL JWT no tiene que ser aceptado si el token es utilizando antes de este tiempo. |
| iat | Issued at | Identifica la marca temporal en qué el JWT fue emitido. |
| jti | JWT ID | Identificador único del token incluso entre diferente proveedores de servicio. |
Los campos siguientes pueden ser utilizados en el encabezado:
| Código | Nombre | Descripción |
| typ | Token type | Si está presente, se recomienda utilizar el valor JWT. |
| cty | Content type | En casos normales, no es recomendado. En casos de firma o cifrado anidado, debe estar presente y el valor debe ser JWT. |
| alg | Message authentication code algorithm | El proveedor de identidad puede elegir libremente el algoritmo para verificar la firma del token, aunque algunos de los algoritmos soportados son inseguros. |
| Cualquiera de los otros campos introducidos por JWS y JWE. |||

## Implementaciones

Algunas de las implementaciones de JWT que existen:
* C
* Common Lisp
* Go
* .NET
* Perl
* Perl6
* PHP
* Python
* Ruby
* Rust
* Scala
* Clojure
* Elixir
* Erlang
* Haskell
* Java
* JavaScript
* Lua
* Node.js
Puede encontrarse una lista detallada con las especificaciones de cada implementación en https://jwt.io/#libraries-io