O Tempo de Vida Real de um JWT: Aritmética de Epoch em iat e exp

Ler uma claim de um JWT é uma consulta direta. Avaliar um token significa fazer aritmética com suas claims, e o número mais importante em uma revisão de autenticação raramente está escrito em algum lugar: por quanto tempo uma credencial roubada continua útil.

Um JWT tem três segmentos separados por pontos, e o payload é codificado em base64url, não criptografado, então ele é decodificado sem nenhuma chave. Duas claims registradas importam aqui. iat é o momento de emissão e exp é o momento de expiração, ambos em segundos de epoch Unix contados a partir de 1 de janeiro de 1970 UTC. Nenhum dos dois é legível por si só, e o token deliberadamente não declara seu tempo de vida.

Este payload traz iat igual a 1788858900 e exp igual a 1796634900. A diferença é de 7776000 segundos, e dividindo por 86400 obtém-se exatamente 90 dias, indo de 8 de setembro a 7 de dezembro de 2026.

O escopo é o que torna esse número sério. Este é um token refresh, cuja única função é gerar novos tokens de acesso. Um access token de vida curta limita o dano a minutos. Um refresh token com noventa dias de vida entrega a um atacante uma chave renovável para a conta por um quarto de ano. O payload também não tem nenhuma claim de dispositivo ou instalação, então nada o vincula ao aparelho para o qual foi emitido, e ele pode ser reproduzido de qualquer lugar. O jti é o único sinal animador, mas um identificador de token só ajuda se o servidor mantiver uma lista de revogação e a consultar em cada troca.

• Enviar um valor de epoch. 1796634900 é o instante de expiração, não o tempo de vida. A resposta é a diferença entre as duas claims.
• Dividir pela constante errada. Um dia tem 86400 segundos. Dividir por 3600 dá horas e por 60 dá minutos.
• Responder em meses. Noventa dias equivalem a cerca de três meses, mas a pergunta pede dias.
• Ler a claim exp como milissegundos. As claims de epoch do JWT estão em segundos. Tratá-las como milissegundos faz o tempo de vida parecer insignificante.
• Supor que a assinatura precisa ser verificada primeiro. O payload é legível de qualquer forma, o que é a lição de fundo sobre JWTs.

A janela de exposição é uma escolha de design, e noventa dias é escolher ter uma.

• Mantenha o tempo de vida do refresh token curto, tipicamente dias em vez de meses, e reautentique em vez de estender indefinidamente.
• Rotacione os refresh tokens a cada uso e detecte a reutilização de um token já rotacionado, o sinal mais forte disponível de que ele foi roubado.
• Vincule o token ao dispositivo ou instalação e rejeite-o quando apresentado por um dispositivo diferente, para que o roubo sozinho não seja suficiente.
• Armazene os refresh tokens em um armazenamento seguro apoiado pela plataforma, o Keychain ou o Keystore, não em shared preferences ou em um plist que acaba em um backup.
• Mantenha uma lista de revogação no lado do servidor indexada por jti e consulte-a em cada troca, para que logout e resposta a incidentes de fato encerrem uma sessão.
• Mantenha os access tokens com duração de minutos, de modo que o refresh token seja a única coisa que vale a pena proteger, e então proteja-o adequadamente.