Por que seu JWT expira imediatamente: exp está em segundos, não em milissegundos

Emitido em 10:00, expirado em 10:00 — um token rejeitado em seu primeiro uso e um relógio de servidor que não era o problema

Um token rejeitado em sua primeira solicitação levanta suspeitas de distorção do servidor, mas inspecione as reivindicações brutas antes de alterar os relógios. Se um componente gerou `exp` a partir de um relógio de milissegundos enquanto outro compara NumericDate segundos, os valores diferem em três ordens de magnitude. Nenhum ajuste de sincronização comum explica essa lacuna.

Use um token descartável ou redigido porque um token ao portador é uma credencial. O decodificador JWT de ToolAcre lê dados de carga útil, mas deliberadamente não verifica assinaturas. Copie a declaração de tempo numérico no conversor de carimbo de data/hora somente após preservar o dispositivo de teste original e sua vida útil pretendida.

O que RFC 7519 diz — NumericDate em segundos desde 1970-01-01T00:00:00Z e por que é um número em vez de uma string

O artigo JWT publicado ao lado já declara o contrato crucial: `exp` NumericDate conta os segundos a partir da época Unix. Repetir a explicação dos padrões não acrescentaria nenhum valor aqui. A questão prática é se cada produtor, serializador, verificador e dispositivo de teste respeita essa mesma escala.

Procure o código de limite explícito: um relógio de milissegundos dividido em segundos durante a emissão e uma comparação de segundos durante a validação. A declaração deve permanecer um número em vez de uma data formatada usada para aritmética. UTC legível por humanos é uma projeção de diagnóstico, não a representação oficial do token.

Fixe este contrato nos testes do emissor e do verificador com um valor diferente de zero. Um teste usando a época zero não pode revelar se um dos lados foi dividido ou multiplicado por mil.

O artigo JWT existente estabelece segundos NumericDate; este artigo aplica esse fato à depuração de expiração

Se um verificador interpretar uma declaração de segundos válida como milissegundos, a data será próxima de 1970 e parecerá expirada. Se um emissor gravar um valor atual de milissegundos em um campo posteriormente interpretado como segundos, a expiração irá muito além do tempo de vida pretendido ou além do intervalo suportado por uma biblioteca. Qual sintoma aparece identifica qual lado possui o erro de escala.

Evite uma “correção” que aceite ambos os formulários com base na contagem de dígitos. Isso transforma tokens malformados em um protocolo alternativo permanente e pode ocultar regressões do emissor. Rejeite valores que violem o contrato NumericDate do aplicativo, corrija a geração e adicione acessórios que distinguem segundos de milissegundos.

Erros de milissegundos podem criar rejeição imediata ou expiração implausivelmente remota, dependendo de qual lado está errado

Decodifique a carga útil para expor `exp`, `iat` e `nbf` como valores brutos antes que uma estrutura os converta. Compare `exp − iat` com o tempo de vida pretendido do token em segundos. Verifique `nbf` separadamente; um token pode não ter expirado, mas não ser utilizável. Não infira autenticidade a partir de tempos aparentemente razoáveis.

O decodificador de ToolAcre relata que a verificação de assinatura é falsa, portanto, sua saída pertence à depuração, nunca à autorização. Uma carga modificada pode conter qualquer prazo de validade escolhido pelo invasor. O verificador de aplicativo confiável ainda deve impor algoritmo, chave, emissor, público e política de tempo no token compacto original.

Exemplo resolvido: uma exp de 1700003600 - convertendo-a para UTC e hora local, verificando-a em relação ao iat e confirmando que o tempo de vida é o que você pretendia

Para `iat = 1,700,000,000` e `exp = 1,700,003,600`, a subtração produz 3,600 segundos ou uma hora. O conversor lê a expiração explicitamente em segundos e retorna `2023-11-14T23:13:20.000Z`; o horário de emissão é `2023-11-14T22:13:20.000Z`.

Esses números são exclusivos do exemplo de diagnóstico deste artigo. Se a seleção de milissegundos produzir uma leitura 1970 de janeiro, isso é uma evidência esperada da escala errada. Confirme se a hora atual do verificador também é expressa em segundos antes de concluir que a política de uma hora foi implementada corretamente.

A diferença de uma hora é calculada antes da formatação, portanto permanece uma hora em cada zona. As exibições locais podem ser diferentes, mas `exp − iat` não.

Exemplo resolvido: compare exp 1,700,003,600 com um iat próximo usando segundos explícitos

Um verificador pode permitir uma pequena tolerância definida pelo aplicativo em relação às declarações de tempo para acomodar diferenças modestas de relógio. Este repositório não define um número recomendado de segundos, portanto, nenhuma margem de manobra universal é prescrita aqui. A política de segurança e a configuração da biblioteca são as autoridades.

A tolerância deve permanecer minúscula em relação a um fator de mil. Expandi-lo até que uma declaração malformada seja aprovada enfraquece a aplicação da expiração e deixa o bug do emissor ativo. Primeiro normalize as unidades de relógio e a sincronização; em seguida, decida se uma permissão local atende ao modelo de risco do aplicativo.

Se uma tolerância estiver configurada, teste os valores dentro e fora desse limite em segundos. Isso comprova a política independentemente de qualquer renderização de data ou localidade.

A tolerância não pode reparar uma incompatibilidade de fator de 1,000

A conversão de carimbo de data/hora não pode verificar a assinatura, algoritmo permitido, chave, emissor ou público de um token. Mesmo uma reivindicação futura `exp` perfeitamente formatada pode ficar dentro de um token forjado. O decodificador JWT é intencionalmente transparente sobre esse limite e deve ser emparelhado com um verificador confiável.

Também não é possível estabelecer se um token de produção capturado foi revogado ou se uma política de sessão substitui seu vencimento nominal. Depurar valores com fixtures não sensíveis. Se um incidente real exigir o exame de credenciais, use o ambiente autorizado e o procedimento de tratamento em vez de um fluxo de trabalho geral da área de transferência.

A decodificação deve acontecer apenas com fixtures sintéticas ou redigidas com segurança durante a depuração de rotina. Copiar uma credencial de portador ativo cria um problema de segurança não relacionado à aritmética do carimbo de data/hora.

Conclusão: exp tem dez dígitos, não treze - e como o decodificador JWT e o conversor de carimbo de data / hora Unix ficam na mesma guia para que você possa verificar uma reivindicação em segundos

Trate as declarações de tempo JWT como segundos em cada limite e teste suas diferenças como durações. O conversor de carimbo de data/hora transforma uma declaração individual em UTC e contexto local; o decodificador JWT expõe o número bruto. Juntos, eles explicam o momento certo sem reivindicar confiança.

A correção durável pertence ao código de emissão e verificação, não a um runbook de suporte que alterna unidades até que um token funcione. Preserve segundos explícitos, rejeite escalas malformadas e mantenha a verificação de assinaturas como uma decisão obrigatória separada.

Essa separação também melhora a observabilidade: os logs de geração podem relatar uma política de duração sem expor tokens, enquanto as métricas de verificação podem distinguir resultados expirados, prematuros e de assinatura inválida.