Decodificador JWT

Anatomía de un JWT

Un JSON Web Token (RFC 7519) es una cadena con tres partes separadas por puntos: header.payload.signature. Cada parte se codifica en Base64 URL-safe sin padding. El header y el payload son JSON normales; la firma es el resultado de aplicar el algoritmo declarado al concatenado de los dos primeros.

El header típicamente tiene dos campos: alg (algoritmo de firma, por ejemplo HS256, RS256, ES256) y typ (siempre JWT). El payload contiene los claims, la información que el servidor confía al cliente.

Claims estándar

El payload puede contener cualquier campo, pero hay siete claims registrados con significado universal:

• iss (issuer): quién emitió el token.
• sub (subject): a quién pertenece (típicamente el ID de usuario).
• aud (audience): a quién va dirigido el token.
• exp (expiration): timestamp Unix de expiración.
• nbf (not before): timestamp antes del cual el token no es válido.
• iat (issued at): timestamp de creación.
• jti (JWT ID): identificador único del token, útil para revocación.

Algoritmos de firma

1. HS256, HS384, HS512: HMAC con SHA-2. Clave simétrica: el mismo secreto firma y verifica. Simple para servicios internos.
2. RS256, RS384, RS512: RSA con SHA-2. Clave asimétrica: privada para firmar, pública para verificar. Estándar para OAuth/OIDC.
3. ES256, ES384, ES512: ECDSA con SHA-2. Como RSA pero con curvas elípticas: firmas más cortas, mejor performance.
4. EdDSA (Ed25519): el más moderno. Firmas de 64 bytes, muy rápido, sin parámetros peligrosos.
5. none: sin firma. Peligroso: nunca aceptes tokens con alg: none en producción.

Cuándo usar JWT (y cuándo no)

JWT está bien cuando necesitás autenticación stateless, claims rica y que el cliente o proxy intermedio pueda leer información sin volver a tu base de datos. Casos prototípicos: APIs federadas, OAuth, OIDC, integraciones con terceros.

JWT NO está tan bien para sesiones de navegador estándar. Una cookie de sesión respaldada por una tabla en tu base es más simple, más segura (revocación inmediata) y no tiene los problemas de tamaño de un JWT. Si tu único caso de uso es "logueado o no", cookie de sesión gana.

Vulnerabilidades comunes

• Algoritmo confundido. Una librería que confía en el header del token puede ser engañada con alg: none o alg: HS256 contra una clave pública. Validá siempre el algoritmo en tu código.
• Sin verificación de firma. Decodificar no es verificar. Algunos códigos solo decodifican y leen los claims sin chequear la firma.
• Sin expiración. Tokens sin exp son válidos para siempre. Aplicá una expiración corta y refresh tokens.
• Información sensible en el payload. El payload no está cifrado, solo firmado. No metas contraseñas, claves o datos privados.
• Sin rotación de claves. Si tu clave HS256 se filtra, podés firmar tokens infinitos. Rotá periódicamente.

Cómo se verifica un JWT en producción

El proceso correcto en el servidor:

1. Leer el algoritmo del header pero no confiar en él: validar contra una whitelist permitida.
2. Verificar la firma con la clave correspondiente.
3. Chequear exp, nbf, iss, aud.
4. Verificar revocación si tenés lista negra (jti).
5. Aceptar y leer los claims.

Este decodificador hace solo el primer paso. Para los demás, necesitás una librería como jsonwebtoken (Node), PyJWT (Python) o jjwt (Java).