Cómo Funciona la Autenticación con JSON Web Token (JWT) Bajo el Capó

Introducción a los JSON Web Tokens

JSON Web Token (JWT) es un estándar abierto (RFC 7519) que define una forma compacta y autónoma de transmitir información de forma segura entre las partes como un objeto JSON. Esta información puede ser verificada y confiable porque está firmada digitalmente. Los JWT se pueden firmar con una clave secreta (con el algoritmo HMAC) o un par de claves pública/privada mediante RSA o ECDSA.

En las arquitecturas web modernas, los JWT se utilizan comúnmente para la autorización sin estado (stateless). Una vez que el usuario inicia sesión, el servidor de autenticación genera un token con información del usuario y lo firma. Para peticiones subsecuentes, el cliente transmite este token, permitiendo al servidor de recursos autenticar al usuario sin consultar una base de datos central o almacenamiento de sesiones.

La Estructura de un JWT

En su formato compacto, un JSON Web Token consta de tres partes separadas por puntos (.):

Cabecera.CargaÚtil.Firma

1. La Cabecera (Header)

La cabecera consta típicamente de dos partes: el tipo de token (JWT) y el algoritmo de firma utilizado, como HMAC SHA256 (HS256) o RSA SHA256 (RS256).

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

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

2. La Carga Útil (Payload)

La carga útil contiene las reclamaciones (claims). Las reclamaciones son declaraciones sobre una entidad (típicamente, el usuario) y metadatos adicionales. Existen tres tipos de reclamaciones:

• Reclamaciones Registradas: Conjunto de reclamaciones predefinidas que no son obligatorias pero sí recomendadas, para proporcionar interoperabilidad. Ejemplos: iss (emisor), exp (fecha de expiración), sub (sujeto) y aud (audiencia).
• Reclamaciones Públicas: Definidas a voluntad. Para evitar colisiones, deben definirse en el registro de JWT de IANA o como una URL resistente a colisiones.
• Reclamaciones Privadas: Reclamaciones personalizadas creadas para compartir información entre partes que acuerdan usarlas (ej. userId o userRoles).

Ejemplo de carga útil:

{
  "sub": "1234567890",
  "name": "Jane Doe",
  "admin": true,
  "iat": 1516239022,
  "exp": 1516242622
}

Esta carga útil se codifica en Base64Url para formar la segunda parte del JWT.

3. La Firma (Signature)

Para crear la firma, se toma la cabecera codificada, la carga útil codificada, una clave secreta, el algoritmo especificado y se firman. Por ejemplo, usando HMAC SHA256:

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

La firma se utiliza para verificar que el remitente del JWT es quien dice ser y para asegurar que el mensaje no fue modificado en el camino.

Validación Criptográfica de la Firma

Cuando un servidor recibe un JWT, debe validarlo antes de realizar operaciones:

1. Divide el token en sus tres partes.
2. Decodifica la cabecera y la carga útil para verificar la estructura, algoritmo y reclamaciones de expiración (exp).
3. Vuelve a calcular la firma utilizando la cabecera, la carga útil y la clave secreta guardada en el servidor.
4. Compara la firma calculada con la firma enviada. Si coinciden exactamente, el token es auténtico.

Consideraciones de Seguridad y Buenas Prácticas

Aunque los JWT son muy eficientes, una mala configuración puede introducir vulnerabilidades críticas:

• Vulnerabilidad "alg": "none": Las primeras librerías permitían tokens firmados con el algoritmo "none". Los atacantes podían modificar el payload, poner "none" y saltarse la validación. Las librerías modernas deshabilitan esto por defecto.
• Entropía de la Clave Secreta: Si usas firmas simétricas (HS256), la clave secreta debe ser larga y compleja para evitar ataques de fuerza bruta offline.
• Firmas Simétricas vs Asimétricas: En arquitecturas de microservicios, los algoritmos asimétricos (RS256 o ES256) son más seguros ya que el servidor de identidad firma con una clave privada y los microservicios validan con la clave pública, manteniendo la clave privada protegida.
• Seguridad en el Almacenamiento: Guardar tokens en LocalStorage los expone a ataques Cross-Site Scripting (XSS). Guardar tokens en cookies con atributos HttpOnly y SameSite los protege de XSS, pero requiere mitigar ataques CSRF.