Back

Decodificador JWT

JSON Web Tokens (JWTs) sao uma forma compacta e segura para URL de representar claims entre duas partes. A maioria dos JWTs sao assinados usando JWS (JSON Web Signature), que garante integridade mas nao criptografa o conteudo. Esta ferramenta decodifica o header e payload para revelar claims, exibe timestamps em formato legivel e mostra o status de expiracao do token.

Especificacoes

Casos de Uso Comuns

  • Depurar fluxos de autenticacao OAuth 2.0 e OpenID Connect
  • Inspecionar access tokens e ID tokens de provedores de identidade (Auth0, Okta, Keycloak)
  • Verificar se as claims do token correspondem aos valores esperados durante desenvolvimento de API
  • Verificar expiracao do token ao solucionar erros "401 Unauthorized"
  • Entender a estrutura do token ao integrar com servicos de terceiros
  • Auditar tokens para revisao de seguranca (algoritmo, claims, expiracao)

Funcionalidades

  • Decodificar header e payload JWT (formato JWS)
  • Exibir algoritmo (HS256, RS256, ES256, PS256, EdDSA) e tipo de token
  • Analisar claims registradas: iss (emissor), sub (sujeito), aud (audiencia), exp (expiracao), nbf (nao antes), iat (emitido em), jti (ID JWT)
  • Mostrar status de expiracao com contagem regressiva legivel
  • Copiar secoes decodificadas como JSON formatado

Exemplos

Token de Acesso OAuth 2.0

Experimente →

Um token de acesso tipico com claims padrao incluindo subject, issuer e expiracao.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyLCJleHAiOjE5MTYyMzkwMjJ9.4S5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5J5

Dicas

  • Tokens JWS (o tipo mais comum) sao assinados mas nao criptografados. Qualquer pessoa com o token pode ler o payload decodificando-o em Base64.
  • Tokens JWE criptografam o payload, mas sao menos comuns. Esta ferramenta decodifica tokens JWS.
  • Sempre verifique assinaturas no lado do servidor antes de confiar nas claims. Esta ferramenta mostra conteudo decodificado mas nao verifica assinaturas.
  • O algoritmo "alg": "none" e um risco de seguranca e deve ser rejeitado por servidores.
  • Algoritmos simetricos (HS256) usam um segredo compartilhado; algoritmos assimetricos (RS256, ES256) usam pares de chaves publica/privada.
  • A claim "exp" e um timestamp Unix em segundos. Verifique-a para evitar aceitar tokens expirados.

Entendendo Decodificador JWT

JSON Web Tokens (JWTs) sao o formato de token dominante para autenticacao e autorizacao web moderna. Um JWT e uma string compacta e segura para URL composta por tres segmentos codificados em Base64url separados por pontos: um header especificando o algoritmo de assinatura, um payload contendo claims sobre o usuario ou sessao, e uma assinatura criptografica que garante que o token nao foi adulterado. Esta estrutura permite que qualquer parte leia o conteudo do token por simples decodificacao Base64, enquanto apenas partes com a chave de assinatura podem criar ou verificar tokens validos.

A maioria dos JWTs usa o formato JWS (JSON Web Signature), onde o payload e assinado mas nao criptografado. O campo "alg" do header especifica o algoritmo: algoritmos simetricos como HS256 usam um segredo compartilhado conhecido tanto pelo emissor quanto pelo verificador, enquanto algoritmos assimetricos como RS256 e ES256 usam uma chave privada para assinatura e uma chave publica para verificacao. Algoritmos assimetricos sao preferidos em sistemas distribuidos porque a chave de verificacao pode ser compartilhada publicamente sem comprometer a chave de assinatura.

O payload contem claims registradas definidas pela RFC 7519: "iss" (emissor), "sub" (sujeito), "aud" (audiencia), "exp" (tempo de expiracao), "nbf" (nao antes), "iat" (emitido em) e "jti" (ID JWT). OAuth 2.0 e OpenID Connect adicionam claims para escopos, funcoes e informacoes de perfil do usuario. A claim "exp" e critica para seguranca — tokens sem expiracao ou com tempos de vida excessivamente longos sao uma vulnerabilidade comum.

JWTs sao usados em access tokens OAuth 2.0, ID tokens OpenID Connect, autenticacao de API e gerenciamento de sessao. Provedores de identidade como Auth0, Okta e Keycloak emitem JWTs que aplicacoes verificam sem contatar o provedor, habilitando autenticacao stateless. No entanto, isso tambem significa que revogacao e dificil — um token comprometido permanece valido ate expirar, razao pela qual tempos de expiracao curtos e fluxos de refresh de token sao praticas de seguranca essenciais.

Como tokens JWS sao codificados em Base64url em vez de criptografados, qualquer pessoa que possua o token pode decodificar e ler o header e payload. Informacoes sensiveis como senhas, numeros de cartao de credito e segredos nunca devem ser colocados em um payload JWT. Tokens JWE (JSON Web Encryption) criptografam o payload, mas sao muito menos comuns na pratica. A distincao entre codificacao e criptografia e uma das coisas mais importantes de entender ao trabalhar com JWTs.

A escolha do algoritmo de assinatura tem implicacoes significativas de seguranca. HS256 e um algoritmo simetrico que usa um unico segredo compartilhado para assinatura e verificacao, tornando-o simples de implementar mas exigindo que ambas as partes armazenem com seguranca o mesmo segredo. RS256 e ES256 sao algoritmos assimetricos que usam uma chave privada para assinatura e uma chave publica para verificacao. Em sistemas distribuidos, algoritmos assimetricos sao preferidos porque a chave publica pode ser compartilhada abertamente — frequentemente atraves de um endpoint JWKS (JSON Web Key Set) — sem comprometer a chave de assinatura. A opcao "alg": "none" sinaliza um token nao assinado sem nenhuma assinatura, significando que qualquer pessoa pode forjar tokens com claims arbitrarias. Um ataque bem conhecido envolve mudar o header do algoritmo para "none" e remover a assinatura. Servidores devem sempre validar o algoritmo contra uma lista de permitidos e rejeitar tokens nao assinados.

Tratamento adequado de expiracao e essencial para seguranca JWT. Aplicacoes devem verificar a claim "exp" em cada requisicao antes de confiar no token. Quando um token expira, um refresh token (armazenado com seguranca, frequentemente em um cookie httpOnly) pode ser usado para obter um novo access token sem exigir que o usuario faca login novamente. Manter os tempos de vida dos access tokens curtos — tipicamente 5 a 15 minutos — limita a janela de exposicao se um token for comprometido. Implementar refresh de token proativamente, antes que o access token realmente expire, evita interrupcoes visiveis para o usuario na aplicacao.

← Voltar para todas as ferramentas