Guía
JWT exp, iat y nbf: cómo interpretar sus fechas
Convierte y diferencia los claims temporales exp, iat y nbf de un JWT sin confundir decodificación con validación.
por Tools in a Tab · Publicado el · Revisado el
Respuesta breve
Los claims exp, iat y nbf describen momentos distintos dentro de un JWT.
Los tres usan NumericDate: segundos desde 1970-01-01T00:00:00Z, ignorando
segundos intercalares. No son milisegundos.
| Claim | Significado | Regla principal |
|---|---|---|
iat |
issued at | Momento en que se emitió el token |
nbf |
not before | No aceptar antes de ese instante |
exp |
expiration time | No aceptar desde ese instante en adelante |
Ejemplo
{
"iat": 1767225600,
"nbf": 1767225600,
"exp": 1767229200
}exp - iat = 3600, así que la ventana indicada dura una hora. Para ver las
fechas, copia cada número al
conversor de timestamp y
selecciona segundos y UTC.
Decodificar no es validar
El decodificador JWT permite leer
cabecera y payload localmente, pero no verifica la firma. Cualquier persona
puede construir una cadena con un exp futuro. Una aplicación solo debe confiar
en los claims después de validar firma o MAC, algoritmo, emisor, audiencia y las
reglas propias del sistema.
Margen de reloj
La RFC 7519 permite
un pequeño margen para compensar relojes ligeramente desincronizados al evaluar
exp y nbf. El tamaño debe ser deliberado y pequeño; añadir un margen grande
extiende en la práctica la validez del token.
Errores frecuentes
- Tratar
expcomo duración en vez de instante absoluto. - Multiplicar un
NumericDatepor1000y guardarlo de nuevo en el JWT. - Considerar válido un token solo porque
expno ha pasado. - Ignorar
nbfo confundirlo coniat. - Mostrar hora local sin indicar la zona.
- Registrar o pegar tokens reales que contienen información sensible.
Para depurar, usa un token de prueba, decodifica localmente, convierte los tres claims en UTC y compara su orden. La decisión de seguridad final debe permanecer en el verificador del sistema, no en una herramienta de lectura.