Comprobar la caducidad de un JWT
El claim exp es una marca de tiempo Unix, que a simple vista no dice nada. Pega el token y esta página lo convierte en una fecha, en tu zona horaria y en una frase clara.
Firma un token propio para probar un endpoint. Todo se calcula en esta página.
La clave y el token terminado se quedan en tu navegador: no se envían a ningún sitio y tampoco viajan en un enlace compartido.
Verifica este token en tu propio código. El fragmento sigue el algoritmo de la cabecera.
Comprobar cuándo caduca un JSON Web Token
Una petición rechazada rara vez sigue siendo un misterio mucho rato: lo primero que conviene mirar es si el token seguía vivo cuando llegó. El problema es que la respuesta está guardada como algo parecido a 1790208000, y eso no lo lee nadie de un vistazo. Pega el token y la línea sobre la cabecera decodificada lo dice en palabras —caducó hace dos días, caduca dentro de cincuenta y ocho minutos, todavía no es válido— mientras la tabla de claims da la fecha completa en tu zona.
Todo se decodifica en la página. Aquí eso importa porque un token es una credencial viva: quien tenga uno válido puede actuar como su sujeto hasta justo el momento del que esta página te está hablando. Nada de lo que pegas se sube, se registra ni se conserva.
Los tres claims que llevan tiempo
| Claim | Significado | Cómo se ve un valor equivocado |
|---|---|---|
exp | El token deja de aceptarse en este momento | Un 401 que aparece siempre al mismo rato de cada inicio de sesión |
nbf | No puede usarse antes de este momento | Un token recién creado rechazado durante sus primeros segundos |
iat | Cuándo se emitió | Lo usan las reglas de antigüedad máxima: un token viejo pero no caducado también falla |
Los tres son segundos desde la época Unix, no milisegundos: un JWT escrito a mano con un Date.now() de JavaScript aterriza en el año 58 000 y no lo acepta nadie. Si necesitas convertir uno de esos números por separado, el conversor de timestamp hace la misma cuenta en ambos sentidos.
¿Caducado o solo descompasado?
Dos máquinas casi nunca coinciden al segundo, así que todo verificador sensato deja cierto margen: entre treinta y sesenta segundos es lo habitual. Esa tolerancia explica que un token pueda parecer caducado aquí por unos segundos y aun así se acepte, y que un token emitido por un servidor con el reloj adelantado se rechace como todavía no válido durante sus primeros instantes. Si un token falla muy lejos de esa ventana, el reloj no es el problema.
La otra mitad de la respuesta es la firma. Un token caducado puede llevar una firma perfectamente buena, y uno falsificado puede llevar un exp muy lejano; son dos preguntas independientes. Esta página responde a las dos: verifica la firma con la clave que hay bajo el token, y un resultado caducado lo sigue diciendo junto al de firma válida.
Cuánto debería durar un token
Poco, porque un token no se puede retirar. Una vez firmado, quien lo tenga es ese usuario hasta que pase exp, de modo que un token de acceso que vive quince minutos limita el daño de una fuga de una forma que uno de treinta días no puede. Lo habitual es combinar un token de acceso corto con un token de refresco largo que se guarda en el servidor y puede revocarse, que es justo el intercambio del que trata la comparación con las cookies de sesión.
Si lo que quieres es probar ese comportamiento en lugar de diagnosticarlo, el generador de JWT firma un token que caduca en cinco minutos, o uno sin caducidad, para que veas cómo reacciona tu propio código.