Codificador/Decodificador JWT

Codificador/Decodificador JWT - Criar e Decodificar Tokens Web JSON Online

Uma poderosa ferramenta online de codificação e decodificação JWT (Token Web JSON) que permite criar novos tokens JWT ou decodificar, inspecionar e entender tokens existentes instantaneamente. Codifique cabeçalho e payload com assinatura HMAC (HS256, HS384, HS512), ou decodifique o cabeçalho (cabeçalho JOSE), payload (claims) e assinatura de qualquer token JWT. Visualize claims padrão como emissor, assunto, audiência, tempo de expiração e mais. Perfeito para desenvolvedores, profissionais de segurança e qualquer pessoa trabalhando com autenticação baseada em JWT, OAuth 2.0, OpenID Connect e segurança de API.

O que é um JWT e qual é sua estrutura?

Um JSON Web Token (JWT, pronunciado "jót") é um padrão aberto (RFC 7519) para representar declarações como uma string compacta e segura para URL. Um JWT tem três partes codificadas em Base64URL unidas por pontos: header.payload.signature. O cabeçalho declara o algoritmo de assinatura e o tipo ({"alg":"HS256","typ":"JWT"}). O payload contém claims como sub (sujeito), iss (emissor), exp (expiração) e dados personalizados. A assinatura é calculada com hash do cabeçalho+payload codificados usando um segredo (HMAC) ou assinando com chave privada (RSA/ECDSA). O token é base64url, não base64, então é seguro em URLs e cabeçalhos HTTP. JWTs são sem estado: o servidor valida a assinatura a cada requisição sem consultar o banco. RFC 7519 é a especificação JWT; RFC 7515 cobre JWS (assinado) e RFC 7516 cobre JWE (criptografado).

O que é a vulnerabilidade alg=none e como prevenir?

alg=none é a vulnerabilidade JWT mais famosa, listada no OWASP API Security Top 10. Um token assinado com alg=none não tem assinatura — mas muitas bibliotecas antigas o aceitavam como "válido" porque honravam o campo algoritmo do cabeçalho sem checar contra uma lista de permissões. Um atacante podia pegar um token real, mudar o cabeçalho para {"alg":"none"}, remover a assinatura, modificar o payload (ex.: role=admin) e o validador quebrado deixava passar. A correção é manter uma lista estrita de algoritmos aceitáveis no servidor (ex.: só HS256 ou RS256) e rejeitar tudo o mais — nunca confie no claim alg do próprio token. O bug companheiro é a confusão HS256/RS256: o atacante envia um token HS256 assinado com a chave pública RSA do servidor como segredo HMAC. Sempre fixe o algoritmo esperado por chave.

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

HS256 (HMAC-SHA256) usa um único segredo compartilhado para assinar e verificar — rápido e simples mas qualquer parte que verifica também pode forjar. Use apenas quando emissor e verificador são o mesmo serviço. RS256 (RSA-SHA256) usa cripto assimétrica: chave privada assina, chave pública verifica. É o padrão para OAuth/OIDC porque provedores de identidade (Auth0, Okta, Google) publicam um endpoint JWKS (JSON Web Key Set) com chaves públicas que clientes buscam para verificar tokens. ES256 (ECDSA P-256) também é assimétrico mas usa curvas elípticas, produzindo assinaturas muito menores (~64 bytes vs ~256 bytes do RS256) — melhor para cenários com banda limitada. EdDSA (RFC 8037) com Ed25519 é a recomendação moderna: mais rápido, menor e resistente a muitos ataques de tempo. Evite RS256 com chaves abaixo de 2048 bits.

Quais são os claims registrados padrão (iss, sub, aud, exp, nbf, iat, jti)?

RFC 7519 define sete claims registrados, todos opcionais mas recomendados. iss (emissor) identifica quem criou o token. sub (sujeito) é o ID do usuário. aud (audiência) lista os destinatários previstos — seu serviço deve rejeitar tokens onde seu identificador não está em aud. exp (expiração) é um timestamp Unix após o qual o token deve ser rejeitado — mantenha curto (15 min para tokens de acesso). nbf (not before) é o momento mais cedo em que o token é válido, útil para ativação programada. iat (issued at) registra quando o token foi criado. jti (JWT ID) é um identificador único por token, permite listas de revogação ou detecção de repetição. Todos os claims de tempo são NumericDate (segundos Unix desde 1970 UTC). Valide sempre exp, nbf, iss e aud — pular qualquer um é um bypass comum.

Onde devo guardar JWTs no navegador — cookie ou localStorage?

Nenhum é perfeito. localStorage é vulnerável a XSS: qualquer script na sua origem pode lê-lo e exfiltrar o token. Cookies são vulneráveis a CSRF se não configurados corretamente, mas mitigações são bem conhecidas. O padrão recomendado pela OWASP são cookies httpOnly + Secure + SameSite=Strict (ou Lax) para o JWT, combinados com um token CSRF em cabeçalho para requisições que mudam estado. httpOnly bloqueia acesso JavaScript (derrota exfiltração via XSS), Secure força HTTPS e SameSite limita envio entre sites. Para SPA + API em origens diferentes, pode precisar SameSite=None; Secure mais CORS explícito. Evite por completo guardar refresh tokens de longa vida em localStorage. Se precisar usar localStorage, trate qualquer XSS como tomada total de conta e invista pesado em cabeçalhos Content Security Policy.

Como funcionam os refresh tokens e por que preciso deles?

Tokens de acesso JWT devem ser de vida curta (5-15 minutos) para que um token vazado tenha valor limitado. Mas forçar o usuário a re-logar a cada 15 minutos é UX ruim, então OAuth 2.0 introduz refresh tokens — strings opacas de vida longa trocadas no endpoint /token por novos tokens de acesso. O refresh token geralmente fica em cookie httpOnly e só é enviado ao servidor de autenticação. Boas práticas: rotacionar refresh tokens a cada uso (RFC 6749bis), revogar a família inteira se um token for repetido (detecção de reuso), vincular refresh tokens ao cliente (PKCE) e guardá-los hasheados no servidor para que um vazamento de BD não os exponha. Clientes públicos (SPAs, apps móveis) devem usar o fluxo PKCE. Refresh tokens são o alvo de alto valor — proteja-os como senhas.

Qual a diferença entre JWT, JWS, JWE e JWK?

São quatro especificações relacionadas mas distintas da família JOSE (JSON Object Signing and Encryption). JWS (RFC 7515) é uma estrutura JSON assinada — o que as pessoas costumam chamar de "JWT." JWE (RFC 7516) é uma estrutura criptografada com cinco partes (header.encryptedKey.iv.ciphertext.tag) onde o payload fica oculto, não só assinado. JWT (RFC 7519) é um formato de payload (claims) que pode ser embrulhado em JWS ou JWE. JWK (RFC 7517) é a representação JSON de uma chave criptográfica, e JWKS é um conjunto delas — normalmente publicado em /.well-known/jwks.json por provedores de identidade. Use JWS quando o payload não é sensível (só assinado para integridade), use JWE quando o payload deve ser confidencial (ex.: contém PII). A maioria dos fluxos OAuth usa JWS, não JWE.

Quais informações devo evitar colocar no payload JWT?

Payloads JWT são codificados em Base64URL, NÃO criptografados — qualquer um com o token pode ler cada claim. Nunca coloque senhas, CPFs, dados de cartão de crédito, segredos de API ou qualquer PII sujeita a LGPD/GDPR/HIPAA/PCI em um payload JWT a menos que use criptografia JWE. Evite também grandes quantidades de dados: cada requisição carrega o token inteiro no cabeçalho Authorization, então payloads inflados desperdiçam banda em cada chamada de API. Mantenha claims em identificadores e escopos de autorização (ID de usuário, papéis, expiração). Para buscas sensíveis, guarde os dados no servidor com chave sub. Evite também colocar dados de usuário mutáveis (nome de exibição, e-mail) que possam mudar — o JWT em cache mostrará valores obsoletos até expirar. O token é uma prova de capacidade, não um perfil de usuário.

Principais Recursos

• Decodificar tokens JWT instantaneamente
• Visualizar cabeçalho (cabeçalho JOSE) com algoritmo e tipo de token
• Visualizar payload com todos os claims e dados personalizados
• Visualizar assinatura (codificada em base64url)
• Detecção automática de claims padrão JWT (iss, sub, aud, exp, nbf, iat, jti)
• Formatação de timestamp legível por humanos para claims de data
• Verificador de status de expiração de token
• Suporte para todos os algoritmos JWT (HS256, HS384, HS512, RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512)
• Realce e formatação de sintaxe JSON
• Seção de informações de claims com explicações detalhadas
• Copiar partes decodificadas para área de transferência
• Baixar saída decodificada
• Carregar arquivos JWT para decodificação
• Suporte a modo escuro
• 100% de processamento no cliente - tokens nunca saem do navegador
• Funciona offline após carregamento inicial
• Sem limites de tamanho de token
• Design responsivo amigável para dispositivos móveis
• Mensagens de erro claras para tokens inválidos
• Informações educacionais sobre segurança JWT
• Nenhum registro ou login necessário