Gerador de JWT Aleatório (Fake)

JWT fake para testar SDK e UI

Um JSON Web Token (RFC 7519, 2015) são três segmentos codificados em Base64url unidos por pontos — header.payload.signature. Um JWT "fake" ou "mock" mantém o formato mas troca a assinatura por bytes aleatórios (ou um secret dummy conhecido), de modo que o token parece real sem dar acesso a coisa nenhuma. É exatamente o que você quer quando está desenhando um SDK, mockando um fluxo OAuth no Postman, semeando uma story do Storybook, montando uma UI de decoder JWT ou gravando fixtures para testes de SDK de API.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decode cada segmento como Base64url e você tem JSON. O header declara o algoritmo: {"alg":"HS256","typ":"JWT"}. O payload guarda claims: as padrão (iss emissor, sub sujeito, aud audiência, exp expiração, nbf not-before, iat issued-at, jti id), as públicas registradas no IANA JWT claim registry e as privadas específicas da aplicação. A assinatura é o que sustenta a confiança; sem ela um JWT é só uma string Base64 com nome chique.

Algoritmos e onde cada um cabe

• HS256 / HS384 / HS512 — HMAC com secret compartilhado. Simétrico: emissor e verificador têm a mesma chave. Padrão para backend único.
• RS256 / RS384 / RS512 — assinatura RSA. Assimétrico: assina com privada, valida com pública. Indicado quando muitos serviços verificam o que um único serviço emite.
• ES256 / ES384 / ES512 — ECDSA em curvas NIST. Mesma história assimétrica do RS*, assinatura mais curta.
• EdDSA — Ed25519. Moderno, rápido, sem armadilhas de parâmetro. Cada vez mais recomendado.
• none — a armadilha clássica: nenhuma assinatura. Bibliotecas precisam recusar; o ataque original alg=none foi uma geração inteira de bugs de identidade.

Tempo de vida dos tokens

APIs maduras separam a credencial em duas: um access token curto (5–15 min) carregado em toda requisição e um refresh token longo (dias ou semanas) guardado em cookie HttpOnly + Secure. Quando o access expira o cliente troca o refresh por um novo par; o próprio refresh rotaciona e é revogado em caso de reuso. Isso limita o estrago de um access token vazado a um quarto de hora. Ferramentas que ajudam: jwt.io (decoder interativo da Auth0), jwt-cli, jose no Node, PyJWT no Python, e a convenção JWKS (/.well-known/jwks.json) para distribuir chaves. No Brasil, APIs públicas como o e-CAC da Receita Federal usam JWT em fluxos de integração.

Vulnerabilidades para deixar no radar

Três bugs clássicos em JWT continuam aparecendo. alg=none: o atacante forja um token sem assinatura; biblioteca mal configurada aceita. Key confusion: o servidor espera RS256 e expõe a chave pública; o atacante troca o header para HS256 e assina usando a pública como secret HMAC. Signature stripping: descarta o terceiro segmento na esperança de que o verificador leia o payload mesmo assim. Mitigações: fixe sempre a lista de algoritmos no verify ({ algorithms: ['RS256'] }), nunca confie em URLs vindas do header (jku / x5u) e guarde tokens em cookie HttpOnly — nunca em localStorage, alcançável por qualquer XSS.

Perguntas frequentes

Serve para teste? Sim — é exatamente o propósito. Use para semear coleções Postman, fixtures de Storybook, mocks de desenho de SDK e UIs de decoder.

Um JWT fake pode forjar acesso real? Não. Sem o secret de assinatura real ou a chave privada, qualquer backend que valide corretamente vai recusar. O token fake só imita o formato.

Onde guardar JWT com segurança na web? Cookies HttpOnly + Secure + SameSite=Lax para refresh tokens; access token só em memória. Evite localStorage: qualquer XSS lê.

JWT vs JWE? Um "JWT" padrão é apenas assinado — o payload é texto claro. JWE (RFC 7516) é a variante cifrada, quando o conteúdo precisa permanecer secreto até para quem carrega.

Posso usar este token em produção? Nunca. É um placeholder. Tokens reais são emitidos pelo seu servidor de auth assinando com um secret ou chave gerado adequadamente.