JWT

Contiene metadatos sobre el token: el algoritmo de firma (alg) y el tipo de token (typ). Siempre JSON codificado en Base64url. La elección del algoritmo aquí afecta la seguridad de todo el token.

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

Contiene las afirmaciones: declaraciones sobre el usuario y metadatos adicionales. También JSON codificado en Base64url. Cualquiera puede decodificar esto — los datos del payload NO están cifrados, solo firmados.

{
  "sub": "user_123",
  "role": "admin",
  "exp": 1717200000
}

Una firma criptográfica sobre el encabezado y el payload codificados. Verificar esta firma garantiza que el token no fue alterado. La clave secreta (HMAC) o la clave privada (RSA/ECDSA) nunca se incluye en el token.

HMACSHA256(
  base64url(header) + "." +
  base64url(payload),
  secret
)

Usa una clave secreta compartida para firmar y verificar. Simple de implementar pero requiere que todos los verificadores conozcan el secreto.

Usa una clave privada para firmar y una clave pública para verificar. La clave privada nunca sale del servidor de autenticación.

Como RSA pero con claves más pequeñas y firma más rápida. Proporciona seguridad equivalente con mejor rendimiento.

Sin firma alguna. Un token con alg:none no tiene garantía de integridad y puede ser falsificado por cualquiera.

Algunas bibliotecas aceptan tokens con alg:none (sin firma). Un atacante puede modificar el payload y establecer alg en none para falsificar cualquier JWT. Siempre especifica y valida explícitamente el algoritmo permitido.

Si una biblioteca espera verificar RS256 pero acepta HS256, un atacante puede firmar un token usando la clave pública como secreto HMAC. Siempre fija el algoritmo esperado.

Un JWT sin reclamación exp, o código que no verifica exp, permite que los tokens se usen indefinidamente. Siempre establece tiempos de expiración cortos y valida la reclamación exp.

Los payloads JWT están codificados en Base64, no cifrados. Nunca almacenes contraseñas, números de tarjetas de crédito u otros secretos en las afirmaciones JWT.

Los JWT firmados con HMAC con secretos cortos o predecibles pueden ser forzados brutos sin conexión. Usa secretos aleatorios criptográficamente de al menos 256 bits.

Aceptar JWTs sin verificar la firma confía completamente en el payload. Siempre verifica la firma antes de confiar en cualquier afirmación.

Los JWT estándar (JWS) están firmados pero NO cifrados. El payload está codificado en Base64url, que es trivialmente reversible. JWE (JSON Web Encryption) proporciona cifrado pero es mucho menos común.

Los tokens de acceso deben ser de corta duración: de 5 a 60 minutos es típico. Usa tokens de actualización (de mayor duración, almacenados de forma segura) para obtener nuevos tokens de acceso.

Las cookies HttpOnly son la opción más segura — son inaccesibles para JavaScript, previniendo el robo por XSS. localStorage es vulnerable a XSS pero evita CSRF. No hay opción perfecta.

No sin estado del lado del servidor. Soluciones: tiempos de expiración cortos, una lista de bloqueo de tokens (Redis) o tokens de sesión opacos para operaciones sensibles.

Las cookies de sesión almacenan un ID de sesión aleatorio; el servidor busca los datos de sesión. Los JWT son autónomos — el servidor valida la firma sin una consulta a la base de datos.

El mínimo: sub (ID de usuario), exp (expiración) e iat (emitido en). Agrega iss (emisor) para configuraciones multi-servicio. Mantén los payloads pequeños.

RS256 (asimétrico) es mejor para la mayoría de los sistemas de producción porque solo el servidor de autenticación necesita la clave privada. Múltiples servicios pueden verificar tokens usando la clave pública.

PKCE (Proof Key for Code Exchange) es una extensión del flujo de código de autorización OAuth2 que previene los ataques de interceptación de código de autorización. Es obligatorio para clientes públicos (SPAs, aplicaciones móviles).