Um JWT decodificado sem verificar a assinatura pode ser confiado por um sistema de backend?

Não. Header e payload são só Base64URL, não criptografia — qualquer pessoa pode ler e reescrever esse conteúdo sem precisar de chave nenhuma. Só a verificação da assinatura (com a chave/certificado correto) confirma que o token não foi adulterado. Confiar em um payload decodificado sem essa verificação equivale a aceitar dado arbitrário do cliente.

O que é o ataque de manipulação do campo alg para 'none' em JWT?

É uma classe de vulnerabilidade onde um atacante altera o campo 'alg' do header para 'none' (indicando ausência de assinatura) e remove a terceira seção do token. Bibliotecas de verificação mal implementadas, que aceitam esse valor sem rejeitá-lo explicitamente, tratam o token como válido mesmo sem nenhuma assinatura real — permitindo forjar qualquer payload.

Por que JWT usa Base64URL em vez de Base64 padrão?

Porque o Base64 padrão usa os caracteres '+' e '/', que têm significado especial em URLs e exigiriam escaping adicional se o token fosse transmitido como parâmetro de URL. Base64URL substitui esses caracteres por '-' e '_', tornando o token diretamente seguro para uso em URLs sem codificação extra.

Decodificador de JWT Online

Decodificador de JWT

Decodifique o header e o payload de um token JWT — sem validar a assinatura.

Token JWT

Header

Payload

Este decodificador apenas lê o conteúdo do token (header e payload são só Base64URL, não criptografia) — não verifica a assinatura, então não confirma se o token é autêntico ou se foi adulterado. Nada é enviado ao servidor.

Documentação técnica

Decodificador de JWT: decodificar não é validar, e essa confusão é uma classe real de vulnerabilidade

Um JWT (JSON Web Token) tem três partes separadas por ponto — header, payload e assinatura — sendo as duas primeiras codificadas em Base64URL (uma variação do Base64 que substitui + e / por - e _, para ser seguro em URLs sem necessidade de escaping adicional). Isso significa uma coisa importante, que este decodificador deixa explícita: header e payload não são criptografados — qualquer pessoa com acesso ao token pode decodificá-los, sem precisar de nenhuma chave. A parte que protege o token contra adulteração não é o Base64URL, é a terceira seção (a assinatura), que este decodificador não verifica.

Por que essa distinção é uma vulnerabilidade real, não só um detalhe técnico

Confundir "consigo ler o conteúdo do token" com "o token é autêntico" já causou incidentes de segurança documentados na prática — o exemplo mais conhecido é o ataque de manipulação do campo alg do header para "none", que, em bibliotecas de verificação mal implementadas (aceitando esse valor como "sem assinatura necessária"), permite forjar um token válido sem conhecer nenhuma chave secreta. Sistemas de backend que decodificam um JWT recebido do cliente e confiam no payload sem verificar a assinatura criptográfica com a biblioteca apropriada (não um decodificador simples como este) estão efetivamente aceitando qualquer dado que o cliente queira enviar.

Uso legítimo deste decodificador: depuração, não autenticação

O caso de uso correto de uma ferramenta como esta é depuração durante desenvolvimento — inspecionar rapidamente o que um token de teste contém (claims, tempo de expiração, algoritmo declarado) sem precisar escrever código ou ter a chave secreta em mãos. Para qualquer decisão de autorização em produção — permitir ou negar acesso baseado no conteúdo de um JWT — a verificação de assinatura com a chave/certificado correto, usando uma biblioteca JWT estabelecida na linguagem do backend, é obrigatória e não-negociável.