Por qué su JWT caduca inmediatamente: exp está en segundos, no en milisegundos

Emitido en 10:00, expiró en 10:00: un token rechazado en su primer uso y un reloj del servidor que no era el problema

Un token rechazado en su primera solicitud invita a sospechar que el servidor está sesgado, pero inspeccione las reclamaciones sin procesar antes de cambiar los relojes. Si un componente generó `exp` a partir de un reloj de milisegundos mientras otro compara los segundos de NumericDate, los valores difieren en tres órdenes de magnitud. Ningún ajuste de sincronización ordinario explica esa brecha.

Utilice un token desechable o redactado porque un token al portador es una credencial. El decodificador JWT de ToolAcre lee los datos de la carga útil pero deliberadamente no verifica las firmas. Copie la declaración de tiempo numérica en el convertidor de marca de tiempo solo después de preservar el dispositivo de prueba original y su vida útil prevista.

Lo que dice RFC 7519: NumericDate en segundos desde 1970-01-01T00:00:00Z, y por qué es un número en lugar de una cadena

El artículo JWT publicado adyacente ya establece el contrato crucial: `exp` NumericDate cuenta los segundos desde la época de Unix. Repetir su explicación estándar no agregaría ningún valor aquí. La pregunta práctica es si cada productor, serializador, verificador y dispositivo de prueba respeta esa misma escala.

Busque un código de límite explícito: un reloj de milisegundos dividido en segundos al emitir y una comparación de segundos al validar. El reclamo debe seguir siendo un número en lugar de una fecha formateada utilizada para aritmética. UTC legible por humanos es una proyección de diagnóstico, no la representación autorizada del token.

Fije este contrato en pruebas de emisor y verificador con un valor distinto de cero. Una prueba que utilice la época cero no puede revelar si alguno de los lados se dividió o se multiplicó por mil.

El artículo JWT existente establece los segundos de NumericDate; este artículo aplica ese hecho a la depuración de caducidad

Si un verificador interpreta un reclamo de segundos válido como milisegundos, la fecha cae cerca de 1970 y parece vencida. Si un emisor escribe un valor actual de milisegundos en un campo que luego se interpreta como segundos, la caducidad va mucho más allá de la vida útil prevista o más allá del rango admitido por una biblioteca. El síntoma que aparece identifica a qué lado pertenece el error de báscula.

Evite una "solución" que acepte ambas formas según el recuento de dígitos. Eso convierte los tokens con formato incorrecto en un protocolo alternativo permanente y puede ocultar las regresiones del emisor. Rechace los valores que violen el contrato NumericDate de la aplicación, corrija la generación y agregue accesorios que distingan segundos de milisegundos.

Los errores de milisegundos pueden generar un rechazo inmediato o una caducidad inverosímilmente remota dependiendo de qué lado esté equivocado.

Decodifica la carga útil para exponer `exp`, `iat` y `nbf` como valores sin procesar antes de que un marco los convierta. Compare `exp − iat` con la vida útil prevista del token en segundos. Marque `nbf` por separado; un token puede no estar caducado pero no ser utilizable. No infieras autenticidad a partir de tiempos que parezcan razonables.

El decodificador de ToolAcre informa que la verificación de la firma es falsa, por lo que su resultado pertenece a la depuración, nunca a la autorización. Una carga útil modificada puede contener cualquier vencimiento que elija un atacante. El verificador de aplicaciones confiable aún debe aplicar la política de algoritmo, clave, emisor, audiencia y tiempo en el token compacto original.

Ejemplo resuelto: una exp de 1700003600: convertirla a UTC y hora local, compararla con iat y confirmar que la vida útil es lo que pretendía

Para `iat = 1,700,000,000` y `exp = 1,700,003,600`, la resta produce 3,600 segundos o una hora. El convertidor lee el vencimiento explícitamente como segundos y devuelve `2023-11-14T23:13:20.000Z`; la hora de emisión es el `2023-11-14T22:13:20.000Z`.

Esos números son exclusivos del ejemplo de diagnóstico de este artículo. Si la selección de milisegundos produce una lectura de enero 1970, se espera evidencia de una escala incorrecta. Confirme que la hora actual del verificador también se exprese en segundos antes de concluir que la política de una hora se implementa correctamente.

La diferencia de una hora se calcula antes de formatear, por lo que permanece una hora en cada zona. Las visualizaciones locales pueden diferir, pero `exp − iat` no.

Ejemplo resuelto: comparar exp 1,700,003,600 con un iat cercano usando segundos explícitos

Un verificador puede permitir una pequeña tolerancia definida por la aplicación en torno a las reclamaciones de tiempo para adaptarse a diferencias de reloj modestas. Este repositorio no define una cantidad recomendada de segundos, por lo que aquí no se prescribe ningún margen de maniobra universal. La política de seguridad y la configuración de la biblioteca son las autoridades.

La tolerancia debe seguir siendo pequeña en relación con un factor de mil. Ampliarlo hasta que se apruebe un reclamo mal formado debilita la aplicación de la caducidad y deja vivo el error del emisor. Primero normalice las unidades de reloj y la sincronización; luego decida si una asignación limitada sirve al modelo de amenaza de la aplicación.

Si se configura una tolerancia, pruebe los valores justo dentro y fuera de ese límite en segundos. Esto prueba la política independientemente de cualquier Fecha o lugar de presentación.

La tolerancia no puede reparar una discrepancia de factor de 1,000

La conversión de marca de tiempo no puede verificar la firma, el algoritmo permitido, la clave, el emisor o la audiencia de un token. Incluso una futura reclamación `exp` perfectamente formateada puede estar dentro de un token falsificado. El decodificador JWT es intencionalmente transparente sobre este límite y debe vincularse con un verificador confiable.

Tampoco puede establecer si un token de producción capturado ha sido revocado o si una política de sesión anula su vencimiento nominal. Valores de depuración con accesorios no sensibles. Si un incidente real requiere examinar las credenciales, utilice el entorno autorizado y el procedimiento de manejo en lugar de un flujo de trabajo general del portapapeles.

La decodificación debe realizarse solo con elementos sintéticos o redactados de forma segura durante la depuración de rutina. Copiar una credencial de portador activo crea un problema de seguridad no relacionado con la aritmética de marcas de tiempo.

Conclusión: exp tiene diez dígitos, no trece, y cómo el decodificador JWT y el conversor de marca de tiempo Unix se ubican en la misma pestaña para que pueda verificar un reclamo en segundos

Trate JWT reclamos de tiempo como segundos en cada límite y pruebe sus diferencias como duraciones. El conversor de marcas de tiempo convierte un reclamo individual en UTC y contexto local; el decodificador JWT expone el número sin formato. Juntos explican el momento oportuno sin pretender confiar.

La corrección duradera pertenece al código de emisión y verificación, no a un runbook de soporte que alterna unidades hasta que un token funciona. Conserve segundos explícitos, rechace escalas con formato incorrecto y mantenga la verificación de firmas como una decisión obligatoria separada.

Esa separación también mejora la observabilidad: los registros de generación pueden informar una política de duración sin exponer tokens, mientras que las métricas de verificación pueden distinguir resultados vencidos, prematuros y de firma no válida.