JWT

JWT (JSON Web Token, pronunciado “jot”) é um formato de token definido no RFC 7519 para transmitir claims assinadas entre partes. Um JWT é três segmentos codificados em base64url separados por pontos: cabeçalho.payload.assinatura.

O cabeçalho declara o algoritmo de assinatura (HS256, RS256, ES256, etc.). O payload é um objeto JSON de claims — sub (sujeito), iss (emissor), exp (validade), iat (emitido em), mais quaisquer campos específicos da aplicação. A assinatura é calculada sobre base64url(cabeçalho) + "." + base64url(payload) usando o algoritmo e a chave declarados no cabeçalho.

JWTs são usados para autenticação sem estado (o servidor não precisa armazenar sessões; verifica a assinatura em cada requisição), autorização entre serviços (tokens bearer OAuth 2.0, tokens de ID do OpenID Connect) e URLs de curta duração que codificam claims de acesso.

Problemas comuns: confiar em alg: none, aceitar tokens com chave simétrica onde assimétrica era esperada, não validar exp. O decodificador JWT inspeciona o conteúdo de um token — ele não verifica a assinatura, porque a verificação requer a chave do emissor.

Exemplo prático

Decodifique o JWT eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NSIsIm5hbWUiOiJBbGljZSIsImlhdCI6MTcxNjQwMDAwMCwiZXhwIjoxNzE2NDg2NDAwfQ.assinatura. Cabeçalho: {"alg":"HS256","typ":"JWT"}. Payload: {"sub":"12345","name":"Alice","iat":1716400000,"exp":1716486400}. O token foi emitido no Unix time 1716400000 (um momento em maio de 2024) e expira 86.400 segundos depois — exatamente 24 horas. Um verificador que recebe este token deve: (1) recalcular HMAC-SHA256 de cabeçalho.payload com o segredo compartilhado e verificar se corresponde à assinatura; (2) verificar exp em relação ao tempo atual e rejeitar se expirado; (3) opcionalmente verificar se iss (emissor) e aud (audiência) correspondem aos valores esperados. Qualquer pessoa — incluindo o navegador do usuário, qualquer proxy intermediário ou um atacante que roube o token — pode decodificar o payload em base64 e ver o nome e o ID de usuário de Alice. O token é assinado, não criptografado.

Quando e por que importa

JWT importa sempre que a autenticação sem estado é a escolha de design — típico para SPAs conversando com APIs REST, aplicativos móveis com serviços de backend, federações OAuth 2.0 / OpenID Connect e autorização serviço-a-serviço em microsserviços. Os erros a evitar: (1) colocar PII ou dados sensíveis no payload (é legível para qualquer pessoa que tenha o token); (2) usar longos prazos de validade sem estratégia de revogação (tokens de 24h+ são perigosos se roubados); (3) aceitar alg: none ou deixar o token escolher o algoritmo; (4) armazenar JWTs em localStorage onde XSS pode roubá-los — prefira cookies httpOnly com SameSite=Lax; (5) não validar aud, aceitando tokens emitidos para serviços irmãos. O padrão que funciona bem: tokens de acesso de 5-15 minutos + tokens de atualização revogáveis de longa duração + sessão opaca no servidor para operações genuinamente sensíveis. Referência: RFC 8725 — Melhores Práticas Atuais para JSON Web Token.

Por que JWTs não são criptografados por padrão: um JWT vanilla é assinado mas não confidencial — qualquer pessoa com o token pode decodificar o payload em base64 e ler todas as claims, incluindo o e-mail do usuário, funções e quaisquer dados específicos da aplicação que o emissor escolheu incorporar. Isso pega engenheiros de surpresa repetidamente: colocar PII ou IDs de usuário internos em um JWT e assumir que o token é uma caixa preta é um vazamento de dados esperando para acontecer. Para confidencialidade, criptografe o payload usando JWE (JSON Web Encryption, RFC 7516), que produz um token de cinco segmentos com criptografia adequada junto com a assinatura. A maioria dos sistemas de produção mantém PII fora do payload ou usa tokens de sessão opacos com pesquisas de estado no servidor.

Tokens de atualização, validade e o problema de revogação: a verificação sem estado é a característica principal do JWT e também sua maior responsabilidade operacional — uma vez emitido, um JWT não pode ser revogado até expirar. A mitigação padrão são tokens de acesso de curta duração (5-15 minutos) emparelhados com tokens de atualização de longa duração (dias a meses) que são revogáveis via lista de negação no servidor; o cliente troca o token de atualização por um novo token de acesso periodicamente. JWTs de longa duração (24 horas ou mais) são um antipadrão para qualquer coisa sensível — um token roubado é um passe livre até expirar. O decodificador JWT do Convertitive destaca a claim exp para que você possa ver rapidamente se um token tem vida útil excessiva. Referência: RFC 7519 — JSON Web Token.