Generador de Cargas Útiles y Constructor de Claims JWT (Estándar RFC 7519) Guía para Desarrolladores

Generador de Cargas Útiles y Constructor de Claims JWT (Estándar RFC 7519) Guía para Desarrolladores

Diseñe claims JWT registrados y personalizados según RFC 7519 con calculadoras de marcas de tiempo para exp, nbf, iat, jti y audiencia.

Presets label
Registered claims
7 / 7 configured
StringOrURI
Principal ID
Target APIs / Clients
https://api.toolsaa.com/v1https://billing.toolsaa.com
In 1h
Quick Lifespan:
Custom claims
Templates:
{
  "iss": "https://auth.toolsaa.com",
  "sub": "usr_89f72b10",
  "aud": [
    "https://api.toolsaa.com/v1",
    "https://billing.toolsaa.com"
  ],
  "exp": 1792178371,
  "nbf": 1792174771,
  "iat": 1792174771,
  "jti": "f81d4fae-7dec-11d0-a765-00a0c91e6bf6",
  "scope": "read:profile write:workspace admin:billing",
  "client_id": "spa_client_prod_442"
}
Stat status
7 / 7 Claims

Standard iss, sub, aud, exp, nbf, iat, jti validation

Stat lifespan
In 1h

Second-level Unix epoch precision

Stat payload size
305 Bytes

~3.7% of 8KB HTTP header buffer

Client-Side Processing

High-performance processing executed entirely in browser memory.

Zero Server Upload Privacy

All data payloads remain strictly local with zero external server communication.

Production Ready Export

Clean, optimized output formats ready for immediate deployment.

Referencia técnica y guía de arquitectura

Generador de Cargas Útiles y Constructor de Claims JWT (Estándar RFC 7519) Guía para Desarrolladores — Guía de referencia

Diseñe claims JWT registrados y personalizados según RFC 7519 con calculadoras de marcas de tiempo para exp, nbf, iat, jti y audiencia.

Parámetros clave y controles

iss (Issuer / Emisor)string

Identifica a la entidad que emitió el JWT (por ejemplo, el URI del servicio de autenticación).

Por defecto: https://auth.example.com
sub (Subject / Sujeto)string

Identifica al sujeto del JWT (generalmente el UUID de usuario o ID de cuenta de servicio).

Por defecto: usr_94b3a8c1-5e2b
aud (Audience / Audiencia)string | string[]

Identifica a los destinatarios previstos del token. El servidor de recursos debe validar que este claim coincida con su identificador.

Por defecto: https://api.example.com/v1
exp (Expiration Time / Expiración)integer (marca de tiempo Unix en segundos)

Tiempo exacto tras el cual el token debe ser rechazado obligatoriamente (NumericDate RFC 7519 en segundos).

Por defecto: 1776435600
jti (JWT ID / Identificador Único)string

Identificador exclusivo del token para prevenir ataques de repetición (replay) y gestionar listas de revocación.

Por defecto: b9c8d6e4-4a2f-48d1-912b-3e5f7a1c8d9e

Consejos profesionales y mejores prácticas

Usar segundos Unix en lugar de milisegundos

El estándar RFC 7519 estipula NumericDate en segundos desde el epoch. Usar 'Date.now()' de JavaScript directamente sin dividir entre 1000 causa que las librerías interpreten la expiración en miles de años o fallen inmediatamente.

Controlar el tamaño del Payload para evitar límites HTTP

Los JWT se transmiten en cada cabecera Authorization o cookie. Evite incluir roles excesivos o perfiles pesados para no superar el límite de 8KB comúnmente configurado en Nginx y Cloudflare.

Configurar margen de tolerancia horaria (Clock Skew)

Los servidores distribuidos pueden presentar ligeros desfases de reloj NTP. Configure un margen de tolerancia (leeway) de 30 a 60 segundos en su verificador para evitar fallos de expiración espurios.

Errores comunes y solución de problemas

El servidor rechaza el token de inmediato con 'TokenExpiredError'

Compruebe si el claim 'exp' se codificó en milisegundos. Emplee 'Math.floor(Date.now() / 1000) + ttl' y configure una tolerancia horaria de 60 segundos en su middleware de backend.

La firma es válida pero la API responde con 'jwt audience invalid' (401/403)

El servidor de destino requiere que su client_id o URI coincida exactamente con el campo 'aud'. Asegúrese de definirlo idénticamente o usar un array si hay múltiples consumidores.

Preguntas frecuentes (FAQ)

¿Cuál es la diferencia entre claims Registrados, Públicos y Privados en RFC 7519?▼

Los claims registrados (iss, sub, aud, exp, nbf, iat, jti) están estandarizados por IANA para interoperabilidad. Los claims públicos son definidos por la comunidad sin colisiones (o mediante URIs). Los claims privados son acordados entre partes para datos personalizados de la aplicación (como roles o tenant_id).

¿Por qué los timestamps de JWT utilizan segundos y no milisegundos?▼

Para alinearse con el estándar de tiempo POSIX y minimizar el número de caracteres dentro de los encabezados HTTP.

¿Es seguro guardar contraseñas o datos bancarios en el payload de un JWT?▼

No. Un token JWS firmado solo está codificado en Base64URL, no cifrado; cualquiera puede leer sus datos. Para información confidencial debe utilizarse JWE (JSON Web Encryption, RFC 7516).

¿Cómo previene el claim 'jti' los ataques de repetición (replay)?▼

Al asignar un UUID único a cada token, el servidor registra el 'jti' consumido en una memoria rápida (como Redis) hasta que venza 'exp'. Si se reenvía el mismo 'jti', se rechaza automáticamente.

Herramientas y utilidades relacionadas

Todas las herramientas →