Cuál es la diferencia entre exp, iat y nbf en un JWT?

iat (Emitido En) es la marca de tiempo cuando se creó el token. exp (Expiración) es cuando el token se vuelve inválido. nbf (No Antes De) es cuando el token empieza a ser válido. En la mayoría de los sistemas, iat y nbf se establecen al mismo valor. La diferencia entre exp e iat define la vida útil del token.

Cómo afecta el skew de reloj a la validación JWT?

Las marcas de tiempo JWT están en UTC y los relojes de los servidores rara vez coinciden exactamente. Si tu servidor está 30 segundos retrasado respecto al servidor de auth y valida exp con tolerancia cero, tokens que aún son válidos serán rechazados. La mayoría de las librerías JWT aceptan un parámetro de tolerancia de reloj (típicamente 30-60 segundos).

Qué pasa si un JWT no tiene claim exp?

El token nunca expira desde la perspectiva del spec (RFC 7519 dice que exp es opcional). Si tu aplicación lo acepta depende de tu lógica de validación. Las implementaciones más conscientes de seguridad rechazan tokens sin claim exp.

Debería poner roles de usuario en las reclamaciones JWT?

Sí, si los necesitas para autorización en la capa API. Incluye un claim de roles o permisos con el conjunto mínimo requerido. No pongas datos altamente sensibles en las reclamaciones porque los JWTs están codificados en base64, no encriptados.

Cómo refresco un JWT antes de que expire?

Usa un flujo de refresh token. El access token de corta vida (15-60 min) es lo que envías con las peticiones API. Cuando expira, intercambias un refresh token de larga vida por un nuevo access token sin re-autenticar al usuario.

DevBento

Herramientas/Decodificador JWT/Reclamaciones JWT Explicadas

Reclamaciones JWT Explicadas

Comprende las reclamaciones de tokens JWT incluyendo exp, iat, nbf, iss, sub, aud. Cubre skew de reloj, patrones de renovación de tokens y errores comunes.

Token Codificado

Herramientas Relacionadas

b64Codificador/Decodificador Base64

Re-encode a decoded header or payload

{}Formateador y Validador de JSON

Formatea, minifica y valida datos JSON al instante. Resaltado de sintaxis, vista de árbol interactiva y detección de errores. Herramienta en tu navegador.

shaGenerador de Hashes

Genera hashes MD5, SHA-1, SHA-256 y SHA-512 a partir de texto o archivos. Usa Web Crypto API para SHA y una implementación en JavaScript puro para MD5.

unixConversor de Tiempo Unix: de Conversión Epoch

Convierte timestamps Unix a fechas legibles o genera timestamps desde fechas. Reloj en vivo, soporte de zona horaria y detección automática de segundos.

Qué Hacen las Reclamaciones JWT

Un JWT son tres segmentos codificados en base64url separados por puntos: header.payload.signature. El payload contiene reclamaciones, que son pares clave-valor que llevan datos de identidad y autorización. Cada reclamación es visible para cualquiera que tenga el token. No hay encriptación, solo una firma que verifica que el token fue emitido por una parte confiable.

Las reclamaciones se dividen en tres categorías:

Reclamaciones registradas: Definidas por el spec JWT (RFC 7519). Incluyen iss, sub, aud, exp, nbf, iat y jti.
Reclamaciones públicas: Registradas en el Registro de Reclamaciones JSON Web Token de IANA o usan un nombre resistente a colisiones.
Reclamaciones privadas: Nombres acordados entre el emisor y el consumidor (ej. role, org_id, permissions).

Las Reclamaciones de Tiempo: iat, nbf, exp

Estas tres reclamaciones forman el ciclo de vida de un token:

iat ──────────── nbf ──────────── token activo ──────────── exp
                  │                                        │
                  └── token empieza a ser válido           └── token expira

iat (Emitido En)

La marca de tiempo Unix cuando se creó el token. Es informativa. No afecta la validación a menos que la lógica de tu aplicación la use para imponer una edad máxima del token.

{
  "iat": 1735603200
}

1735603200 = 1 de enero de 2025 a las 00:00:00 UTC.

nbf (No Antes De)

La marca de tiempo Unix cuando el token se vuelve válido. Si un token llega con un nbf en el futuro, el servidor debe rechazarlo. Esto es raro en la práctica. La mayoría de los sistemas establecen nbf igual a iat.

{
  "nbf": 1735603200
}

exp (Expiración)

La marca de tiempo Unix cuando el token se vuelve inválido. Esta es la reclamación de tiempo clave. El servidor debe rechazar cualquier token con exp en el pasado.

{
  "exp": 1735689600,
  "iat": 1735603200
}

La diferencia es 86400 segundos (24 horas). Este token tiene una vida útil de un día.

Reclamaciones Registradas Estándar

Más allá de las reclamaciones de tiempo, el spec JWT define varias reclamaciones estándar:

Reclamación	Nombre	Propósito	Ejemplo
`iss`	Emisor	Quién creó el token	`"https://api.example.com"`
`sub`	Sujeto	A quién representa el token	`"user_12345"`
`aud`	Audiencia	Para quién es el token	`"https://app.example.com"`
`exp`	Expiración	Cuándo expira el token	`1735689600`
`nbf`	No Antes De	Cuándo se vuelve válido el token	`1735603200`
`iat`	Emitido En	Cuándo se creó el token	`1735603200`
`jti`	ID JWT	Identificador único del token	`"abc-123-def"`

iss (Emisor): Identifica quién creó el token. Tu servidor de auth debe validar esto para prevenir que tokens de otros emisores sean aceptados.

sub (Sujeto): La entidad que representa el token. Típicamente un ID de usuario o nombre de cuenta de servicio. Usa esto en tu lógica de autorización para identificar quién está haciendo la petición.

aud (Audiencia): Para quién fue emitido el token. Si tu sistema tiene múltiples servicios (ej. API gateway, servicio de usuario, servicio de pago), cada uno debe verificar que el claim aud coincida con su propio identificador.

jti (ID JWT): Un identificador único para el token. Usa esto para revocación de tokens. Almacena el jti en una lista de denegación cuando el usuario cierra sesión o el token es revocado.

Skew de Reloj: Por Qué los Tokens Son Rechazados Prematuramente

Los relojes de los servidores nunca están perfectamente sincronizados. Si el reloj del servidor de auth está 30 segundos adelante del servidor de API, un token con exp = 1735689600 podría validarse contra un servidor que cree que ya son 1735689631.

La solución es una ventana de tolerancia:

// Node.js con jsonwebtoken
jwt.verify(token, secret, { clockTolerance: 30 }); // 30 segundos de tolerancia

// Go con golang-jwt
token, err := jwt.Parse(tokenString, keyFunc,
    jwt.WithLeeway(30 * time.Second),
)

Una tolerancia de 30-60 segundos es estándar. No la establezcas en cero o verás errores 401 intermitentes difíciles de depurar.

Errores Comunes

Usar exp con segundos vs milisegundos

Algunas librerías usan segundos (estándar RFC 7519), otras milisegundos. Un token con exp: 1735689600 (segundos) parece año 56935 si se interpreta como milisegundos. Verifica la expectativa de tu librería.

Establecer exp demasiado lejos en el futuro

Un token con vida útil de 30 días significa que un token robado es usable por 30 días. Los access tokens deben expirar en 15-60 minutos.

Validación aud faltante

Si tu API no verifica el claim aud, un token emitido para un servicio diferente puede usarse contra tu endpoint. Siempre valida iss y aud.

Almacenar datos sensibles en reclamaciones

Las reclamaciones son legibles por cualquiera que tenga el token. No pongas contraseñas, SSN o claves privadas en reclamaciones JWT.

Decodificando el Token de Ejemplo

Pega el token de ejemplo en JWT Decoder para ver todas las reclamaciones decodificadas. El payload contiene:

{
  "iss": "https://api.example.com",
  "sub": "user_12345",
  "aud": "https://app.example.com",
  "exp": 1735689600,
  "iat": 1735603200,
  "nbf": 1735603200,
  "role": "admin",
  "permissions": ["read", "write", "delete"]
}

El token fue emitido a medianoche UTC del 1 de enero de 2025, expira 24 horas después, y otorga acceso de admin a user_12345.

🔒

Nothing you paste leaves this tab. Every tool runs entirely in your browser — no upload, no server, no account.