JWT (JSON Web Token) é um formato compacto para transmitir dados assinados, na maioria das vezes informações sobre um usuário autenticado. Um token tem três partes separadas por pontos: header.payload.signature. No Brasil, é a base de autenticação de praticamente todo sistema que se integra ao Pix e ao Open Finance regulado pelo Banco Central.
Acentos e cedilha nos claims
Um payload como {"nome": "João da Conceição", "cidade": "São Paulo"} é codificado normalmente em Base64URL: o processo trabalha sobre bytes UTF-8, sem distinguir letras acentuadas de ASCII simples. Na prática, isso significa que cada ã, ç ou é ocupa 2 bytes em vez de 1, então um token com nomes brasileiros reais fica um pouco mais longo do que um equivalente só com caracteres ASCII — algo que raramente aparece nos tutoriais, mas afeta o tamanho real do header Authorization enviado em cada requisição.
As três partes de um token
- Header — um JSON com o tipo de token e o algoritmo de assinatura (por exemplo, HS256 ou RS256), codificado em Base64URL.
- Payload — um JSON com os "claims": dados do usuário, momento de emissão, expiração, etc., também em Base64URL.
- Signature — uma assinatura calculada sobre o header e o payload usando uma chave secreta ou privada, confirmando que o token não foi alterado.
Base64URL, não Base64 comum
O JWT usa uma variante do Base64 com alfabeto seguro para URL: os caracteres + e / são substituídos por - e _, e o preenchimento = costuma ser omitido. Isso permite inserir um token numa URL ou cabeçalho sem codificação adicional.
Uma distinção importante: decodificar ≠ verificar
O header e o payload são apenas Base64URL: qualquer pessoa pode decodificá-los e ler o conteúdo sem nenhuma chave. Decodificar um token não prova que os dados não foram alterados. Só se pode confiar no conteúdo de um token depois de verificar sua assinatura com a chave correspondente — e essa verificação é feita pelo servidor, não por um cliente que apenas olha o que está dentro do token.
Ataque perigoso: troca do algoritmo por "none"
A especificação do JWT permite o algoritmo none — um token sem assinatura. Se o backend confia ingenuamente no campo alg do cabeçalho do token em vez de verificar a assinatura com um algoritmo fixo e conhecido de antemão, um atacante pode trocar alg por none, remover a assinatura, e o token passa na verificação com dados arbitrários. Bibliotecas JWT robustas exigem que o algoritmo esperado seja explicitamente informado na verificação justamente para se proteger desse ataque.
Um caso real: fintechs e o ecossistema Pix
Boa parte das fintechs brasileiras — e as APIs de Open Finance homologadas pelo Banco Central — usam JWTs de curta duração combinados com um refresh token separado, seguindo o padrão FAPI (Financial-grade API), que é ainda mais rígido que um JWT comum quanto ao algoritmo de assinatura aceito. Conferir o campo exp de um token costuma ser o primeiro passo para entender por que uma integração bancária parou de responder do nada.