O que é um JWT e por que você não deve guardar segredos dentro dele?
Publicado em 2026-10-20 por frfrand
JWT explicado desde cero: header, payload y firma, diferencias con cifrado, expiración y precauciones de seguridad.
Um JWT é um formato de token que permite transportar afirmações ou dados entre sistemas. Muitas aplicações o utilizam para trocar informações sobre sessões e permissões. O nome vem de JSON Web Token.
O aviso mais importante é este: um JWT assinado normalmente não está criptografado. Parecer uma string ilegível não significa que seja um lugar seguro para guardar senhas.
As três partes que costumam aparecer
Um JWT compacto assinado costuma conter três segmentos separados por pontos:
encabezado.contenido.firmaO cabeçalho indica informações como o algoritmo. O conteúdo — ou payload — leva afirmações conhecidas como claims. A assinatura permite comprovar integridade e autenticidade sob determinadas condições, se for validada corretamente.
Os segmentos usam representações que podem ser decodificadas. Por isso um identificador de usuário ou uma data de expiração pode ser lido sem conhecer uma senha secreta.
Para que serve?
Imagine que um usuário se autentica em um aplicativo. O servidor pode emitir um token que outro componente valida para reconhecer certas afirmações durante sua vigência.
Em algumas arquiteturas isso simplifica a comunicação entre serviços. Em outras, uma sessão tradicional mantida no servidor resulta mais simples e permite revogação imediata com menos complicações.
Não existe obrigação de utilizar JWT só porque você desenvolve uma API moderna.
O que significam exp, iss e aud?
exp é uma afirmação comum sobre expiração, iss identifica o emissor e aud indica o público-alvo pretendido.
Uma implementação segura não se limita a verificar a assinatura. Também deve verificar qual emissor é confiável, para qual público o token foi emitido, se já expirou e se as permissões declaradas são pertinentes para a operação.
Um token válido para outra API não deveria poder ser reutilizado indiscriminadamente na sua.
JWT significa que não preciso de banco de dados?
Não necessariamente. Sua aplicação pode continuar consultando permissões, status de contas ou recursos. Um usuário pode perder acesso a um projeto antes que o token recebido expire.
Se toda a autorização depender de afirmações desatualizadas, você poderá permitir ações que já foram revogadas. A política de expiração e o mecanismo de revogação devem ser projetados pensando nesse risco.
Onde o token é armazenado no navegador?
É uma decisão com trade-offs. Armazená-lo em armazenamento acessível por JavaScript pode aumentar o impacto de certos ataques XSS. Cookies com atributos adequados podem reduzir determinados riscos, mas também devem ser considerados CSRF, escopo de domínio e duração.
Não existe uma resposta única sem conhecer a arquitetura. Evite repetir receitas do tipo «JWT sempre em localStorage» ou «JWT sempre em cookies» sem avaliar o modelo de ameaças.
Erros frequentes
Colocar segredos no payload. Se o token não estiver cifrado, esses dados são recuperáveis.
Aceitar algoritmos ou emissores inesperados. A validação deve ser estrita e utilizar uma configuração confiável.
Usar expirações excessivas sem revogação. Se o token for vazado, pode permitir acesso por mais tempo do que o razoável.
Confundir JWT com OAuth. Um é um formato; o outro é um framework de autorização. Podem ser usados juntos, mas não são sinônimos.
Um exemplo em ArduMaker
Se uma aplicação hospedada em um VPS gerenciado pelo ArduMaker utiliza tokens JWT, o servidor da aplicação deve validá-los corretamente e verificar permissões sobre cada recurso. A hospedagem não converte automaticamente um token inseguro em confiável.
Para lembrar: a assinatura de um JWT ajuda a comprovar sua integridade, não a ocultar seu conteúdo. A segurança depende de como ele é emitido, validado, armazenado e revogado.
Fontes: RFC 7519, JSON Web Token · Boas práticas de JWT na OWASP.