Gerador JWT gratuito

O que um JWT realmente é

Um JSON Web Token (JWT), pronunciado «djot», é uma representação compacta e segura para URL de afirmações a transferir entre duas partes. O formato são três segmentos codificados em Base64url separados por pontos: cabeçalho.payload.assinatura. O cabeçalho declara o tipo de token (sempre JWT) e o algoritmo de assinatura (comumente HS256, RS256 ou ES256). O payload carrega as afirmações, um objeto JSON com campos padrão como iss (emissor), sub (assunto), aud (audiência), exp (tempo de expiração como timestamp Unix), nbf (não antes), iat (emitido em), jti (ID do JWT), além de quaisquer afirmações específicas da aplicação que o emissor queira incluir. A assinatura é a prova criptográfica de que cabeçalho e payload não foram alterados, produzida ao assinar a string concatenada base64url(cabeçalho).base64url(payload) com o algoritmo e a chave declarados no cabeçalho. JWT foi especificado por Michael B. Jones, John Bradley e Nat Sakimura como RFC 7519 em maio de 2015, com base em trabalhos anteriores de JOSE (JSON Object Signing and Encryption, RFCs 7515 a 7520). O formato tornou-se a forma de token dominante na autenticação web moderna, usada por implementações OAuth 2.0 / OIDC, gateways de API, tokens de sessão de SPAs, autenticação microsserviço-a-microsserviço e gestão de sessão por cookie em larga escala.

A escolha do algoritmo de assinatura, HS256 vs RS256 vs ES256

JWT suporta vários algoritmos de assinatura registrados no registro de algoritmos JOSE (RFC 7518). HS256 (HMAC-SHA256) é o mais simples: um algoritmo simétrico em que o mesmo segredo é usado para assinar e verificar. Barato de calcular, fácil de implementar e apropriado quando assinante e verificador são a mesma parte (por exemplo, uma única aplicação que emite tokens de sessão para si mesma). RS256 (RSA-SHA256) é assimétrico: a chave privada assina, a chave pública verifica. Usado quando emissor e verificador são partes diferentes, Auth0, Okta, Google Identity Platform, Microsoft Entra ID e a maioria dos provedores de identidade na nuvem emitem JWTs assinados com RS256 porque os clientes podem verificar a assinatura usando um endpoint JWKS (JSON Web Key Set) publicado sem precisar compartilhar segredos. ES256 (ECDSA P-256 SHA-256) é o equivalente em curva elíptica do RS256, mesmo modelo de chave pública/privada, chaves bem mais curtas (256 bits contra o mínimo de 2048 do RSA), verificação mais rápida. EdDSA (Ed25519) é o sucessor moderno do ES256, ligeiramente mais rápido e com propriedades criptográficas mais limpas; suportado em bibliotecas JWT mais novas mas ainda não universal. none é um modo «sem assinatura» permitido pela especificação JWT que provocou incidentes de segurança em várias bibliotecas quando implementações não rejeitavam tokens alg: none: a lição é que verificadores JWT precisam checar explicitamente que o algoritmo coincide com o esperado. Este gerador usa HS256 porque exige apenas um segredo compartilhado em vez de geração de chaves; para uso em produção de algoritmos assimétricos, uma biblioteca do lado do servidor é a ferramenta certa.

Quando você precisa gerar um JWT à mão

• Testar endpoints de API. Uma API exige um JWT no cabeçalho Authorization, para testá-la manualmente com curl, Postman ou HTTPie, você precisa de um token. Gere um JWT de teste no formato certo, assine-o com o segredo compartilhado da API (em ambientes de dev) e use o resultado.
• Reproduzir um bug relacionado a tokens. Um usuário reporta um problema de autenticação. Reconstrua o token que ele teria recebido com suas afirmações, examine a assinatura, verifique a lógica de verificação do seu serviço contra um token conhecido-bom e um conhecido-mau.
• Desenvolvimento local sem provedor de auth. Você está construindo um frontend contra uma API que espera autenticação JWT, mas ainda não tem acesso ao provedor de identidade de produção. Gere JWTs de teste com afirmações realistas para o desenvolvimento.
• Aprender o formato JWT. Decodifique um JWT, mude uma afirmação, reassine-o, veja o que sua aplicação faz. O loop de depurar-mexendo é como a maioria dos desenvolvedores acaba entendendo a estrutura JWT.
• Tokens internos serviço-a-serviço. Dois microsserviços internos compartilham um segredo e usam JWT para autenticar requisições. O modelo HS256 de segredo compartilhado é apropriado aqui; esta ferramenta pode gerar os tokens manualmente para teste.

Armadilhas de segurança, onde JWTs dão errado

JWTs têm um longo histórico de erros de implementação que produziram incidentes reais de segurança. O ataque «alg: none»: bibliotecas JWT iniciais aceitavam tokens com o campo de algoritmo definido como «none» (sem assinatura), permitindo que um atacante forjasse qualquer token. Verificadores precisam impor explicitamente o algoritmo esperado. Confusão de algoritmo: um verificador que aceita tanto RS256 quanto HS256 pode ser enganado usando a chave RSA pública como segredo HMAC, o atacante assina com HS256 usando a chave pública, e o verificador (mal-)verifica com HMAC usando a mesma chave pública. Verificadores precisam fixar o algoritmo esperado. Dados sensíveis no payload: afirmações JWT são codificadas em Base64 mas não criptografadas. Qualquer um com o token pode ler cada afirmação. Nunca coloque senhas, números completos de cartão de crédito ou outros segredos no payload. Sem expiração: JWTs sem afirmação exp são válidos para sempre. Sempre defina uma expiração razoável (minutos para tokens de acesso, dias para tokens de refresh). Sem revogação: JWTs são autocontidos, uma vez emitidos, permanecem válidos até exp independentemente de o usuário fazer logout, trocar a senha ou ter a conta suspensa. Aceite essa limitação, mantenha uma lista de revogação (o que anula em parte o ponto do token sem estado), ou use tokens de acesso de curta duração com rotação de tokens de refresh. Armazenar em localStorage vs cookies: um JWT em localStorage é acessível a qualquer JavaScript da página (risco de XSS); um JWT em cookies HttpOnly não é (mas é enviado automaticamente em requisições cross-origin, risco de CSRF). Ambos têm trade-offs; a boa prática moderna tende a cookies HttpOnly com restrições SameSite mais tokens CSRF.

JWT vs cookies de sessão vs PASETO

JWT não é a única opção. Cookies de sessão tradicionais guardam um ID de sessão opaco; o servidor mantém o estado real da sessão em um banco de dados ou cache. Vantagens: revogação trivial (apagar o registro do servidor), sem risco de vazamento de dados de afirmações, sem complexidade de assinatura. Desvantagens: exige consulta ao store de sessão a cada requisição (latência), mais difícil de escalar entre serviços. PASETO (Platform-Agnostic Security Tokens, Scott Arciszewski 2018) é um substituto de JWT projetado para evitar as armadilhas de confusão de algoritmo e «none», formato versionado, sem negociação de algoritmo, assinaturas obrigatórias, escolhas de cifra restritas. PASETO ganhou tração em contextos sensíveis a segurança mas não deslocou JWT no ecossistema mais amplo. Macaroons (Google, 2014) são um formato de token mais flexível com restrições de capacidade encadeadas, mas em 2026 são essencialmente coisa de pesquisa. OAuth 2.1 consolida as boas práticas do OAuth 2.0, JWT continua sendo o formato típico de token de acesso. A escolha pragmática em 2026 continua sendo JWT para microsserviços sem estado e tokens de API, cookies de sessão opacos para apps web tradicionais renderizadas no servidor, com PASETO como alternativa moderna para projetos novos que querem defaults mais fortes.

Perguntas frequentes

Posso decodificar um JWT sem a chave secreta?

Sim. Os JWTs são assinados, mas não criptografados, então o cabeçalho e o payload podem sempre ser lidos. A chave secreta só é necessária para verificar a assinatura ou gerar um novo token.

É seguro colar JWTs de produção aqui?

Sim. Todo o processamento ocorre localmente no seu navegador. Seus tokens e chaves secretas nunca são enviados para um servidor nem armazenados em nenhum lugar.

Qual é a diferença entre HS256, RS256 e ES256?

HS256 usa uma chave secreta compartilhada (HMAC-SHA256). RS256 usa pares de chaves RSA, ES256 usa criptografia de curva elíptica. Esta ferramenta suporta HS256, o mais comum para APIs web.