Los JSON Web Tokens (RFC 7519) son el estándar de facto para transportar claims firmados entre servicios. Este generador firma JWTs con HS256, HS384 o HS512 usando la Web Crypto API del navegador. Ideal para pruebas de integración, mocks o entender cómo se compone el token pieza a pieza (header, payload, signature).
Estructura de un JWT
Tres bloques Base64URL separados por puntos: header (algoritmo y tipo), payload (claims) y firma. El servidor solo confía en el token si la firma es válida con la clave secreta correcta. Nunca metas datos sensibles en el payload: no está cifrado, solo firmado; cualquiera con el token puede leerlo.
Claims estándar y personalizados
El RFC define siete claims registrados: `iss` (issuer), `sub` (subject), `aud` (audience), `exp` (expiración), `nbf` (not before), `iat` (issued at) y `jti` (JWT ID). Añade los tuyos con nombres cortos pero descriptivos (`role`, `tenant`, `scope`). Mantén el token pequeño: cada byte viaja en cada request.
HS vs RS: cuándo cambiar
HS256 usa una clave simétrica: el emisor y el verificador comparten el mismo secreto. Va bien para arquitecturas monolíticas o cuando el mismo servicio emite y valida. Para microservicios, usa RS256 (RSA) o ES256 (ECDSA): un servicio firma con clave privada y los demás verifican con la pública, sin exponer el secreto.
Casos de uso comunes
- Firmar tokens de prueba para tests de integración.
- Enseñar cómo funciona OAuth 2.0 y OpenID Connect.
- Reproducir bugs de expiración o clock skew.
Buenas prácticas
- Nunca uses `none` como algoritmo: hay CVEs históricos por librerías que lo aceptaban por defecto.
- Rota el secreto HS256 periódicamente y usa longitud >= 256 bits.
- Siempre valida `exp`, `iss` y `aud` en el verificador.