BrowserTools
Publicidade
Início / Codificadores / Descodificador JWT

Descodificador JWT

Descodifica e inspeciona JSON Web Tokens localmente: cabeçalho, carga útil e claims de expiração.

Mantido por BrowserTools · Última atualização 2026-06-06

A carregar Descodificador JWT… Se nada acontecer, ativa o JavaScript.

Um JSON Web Token (JWT) é uma cadeia compacta e segura para URL que codifica um conjunto assinado de claims (afirmações sobre um utilizador, uma sessão ou uma permissão) num formato que qualquer parte que tenha a chave certa pode verificar de forma independente. Definido pelo RFC 7519 (2015) e parte da família de normas JOSE (assinatura e cifragem de objetos JSON), os JWT tornaram-se rapidamente o mecanismo dominante para a autenticação sem estado e a autorização de API em arquiteturas web, móveis e de microsserviços. Um JWT é composto por três segmentos codificados em Base64url e separados por pontos: o cabeçalho (metadados do algoritmo), a carga útil (os claims) e a assinatura.

Exemplos

Entrada eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0.<sig>
Saída Header {"alg":"HS256","typ":"JWT"} · Payload {"sub":"1234567890","name":"John Doe"}

Um JWT são três partes em Base64url unidas por pontos: cabeçalho.carga_útil.assinatura.

Perguntas frequentes

O meu token é enviado para um servidor?
Não. A descodificação acontece inteiramente no teu navegador usando a função atob integrada do JavaScript e o JSON.parse. O teu JWT, que pode conter a identidade do utilizador, permissões ou dados de sessão, nunca sai do teu dispositivo e nunca é enviado pela rede.
Quais são as três partes de um JWT?
Um JWT são três objetos JSON codificados em Base64url e separados por pontos. O cabeçalho declara o tipo de token ('JWT') e o algoritmo de assinatura (por exemplo, HS256, RS256). A carga útil contém os claims: campos padrão como iss (emissor), sub (sujeito), exp (expiração), iat (emitido em), mais quaisquer claims personalizados da aplicação. A assinatura é calculada pelo servidor emissor sobre o cabeçalho e a carga útil, e permite aos destinatários verificar que o token não foi adulterado.
Quando devo usar um JWT na minha própria aplicação?
Os JWT são ideais para autenticação sem estado: uma vez emitidos, o servidor não precisa de guardar o estado da sessão, o próprio token transporta tudo o que é necessário para autorizar um pedido. Encaixam bem em microsserviços e API onde vários serviços precisam de verificar a identidade sem partilhar uma base de dados de sessões. Funcionam bem para tokens de acesso de curta duração (minutos a horas). Para sessões de longa duração onde precisas de revogação instantânea, uma sessão tradicional do lado do servidor com consulta a uma base de dados é muitas vezes mais apropriada.
Em que difere um JWT de um cookie de sessão?
Um cookie de sessão guarda um identificador opaco aleatório; o servidor procura os dados reais da sessão numa base de dados em cada pedido. Um JWT é autónomo: o servidor valida a assinatura e lê os claims do próprio token, sem necessidade de consultar uma base de dados. Por isso, os JWT são mais rápidos e fáceis de escalar horizontalmente, mas mais difíceis de revogar: não podes 'terminar a sessão' de um JWT antes de ele expirar a menos que mantenhas uma lista de bloqueio de tokens, o que reintroduz estado no servidor.
Esta ferramenta verifica a assinatura do JWT?
Não, e deliberadamente. A verificação da assinatura requer a chave secreta do emissor (para algoritmos HMAC como HS256) ou a sua chave pública (para algoritmos RSA/ECDSA como RS256). Nunca deves colar uma chave secreta em qualquer ferramenta de terceiros. Este descodificador mostra-te o cabeçalho e os claims da carga útil descodificados apenas para fins de inspeção. Para a verificação de assinaturas em produção, usa uma biblioteca de confiança no teu próprio ambiente.
O que significam os claims padrão de marca temporal?
iat (issued at) é a marca temporal Unix de quando o token foi criado. exp (expiration time) é a marca temporal a partir da qual o token deve ser rejeitado. nbf (not before) é a marca temporal antes da qual o token não deve ser aceite. As três são segundos desde a época Unix (1 de janeiro de 1970 UTC). Esta ferramenta converte-as automaticamente em datas legíveis para que vejas de imediato se um token expirou ou ainda não é válido.
Pode usar-se um JWT sem assinatura (alg: none)?
A especificação do JWT permite tecnicamente um token não seguro com 'alg': 'none' e uma assinatura vazia. No entanto, aceitar tais tokens em produção é uma vulnerabilidade de segurança crítica. Várias bibliotecas JWT iniciais confiavam em 'alg': 'none' por omissão, permitindo a atacantes forjar tokens arbitrários. Configura sempre a tua biblioteca JWT para exigir um algoritmo específico e rejeitar tokens com 'alg': 'none', a menos que tenhas uma razão muito concreta para permitir tokens não assinados.
As cargas úteis dos JWT são privadas e confidenciais?
Não. Um JWT padrão (JWS, assinatura web JSON) assina a carga útil para garantir a integridade, mas não a cifra. A carga útil está simplesmente codificada em Base64url, que qualquer pessoa pode descodificar de imediato. Nunca incluas informação sensível (palavras-passe, números de cartão, documentos de identidade ou quaisquer dados que não queiras expor) na carga útil de um JWT. Se precisas de tokens cifrados, usa JWE (cifragem web JSON), que é uma norma separada.
Qual é a diferença entre HS256 e RS256?
O HS256 usa HMAC-SHA256: a mesma chave secreta é usada para assinar e verificar o token, tornando-o um esquema simétrico. É simples, mas significa que cada serviço que verifica tokens tem de conhecer o segredo. O RS256 usa RSA-SHA256: o emissor assina com uma chave privada e qualquer serviço pode verificar com a chave pública correspondente. O RS256 é preferido em arquiteturas multisserviço porque as chaves públicas podem ser partilhadas livremente através de um ponto de acesso JWKS, sem expor o segredo de assinatura.
Qual é um erro comum que os programadores cometem com os JWT?
O erro mais comum é tratar uma assinatura válida como prova de autorização sem verificar também o claim exp: um token expirado com uma assinatura válida deve ser sempre rejeitado. Um segundo erro muito próximo é guardar o JWT no localStorage em vez de num cookie HttpOnly, o que o expõe a qualquer JavaScript na página (ataques XSS). Um terceiro problema é pôr demasiados dados na carga útil do JWT: tokens grandes acrescentam latência a cada pedido porque têm de ser transmitidos em cada cabeçalho HTTP.

Sobre Descodificador JWT

Os JWT aparecem em praticamente todos os fluxos de autenticação modernos. Os tokens de acesso OAuth 2.0 são quase universalmente emitidos como JWT. Os tokens de identidade do OpenID Connect são JWT que transportam os claims de identidade do utilizador autenticado. Os sistemas de início de sessão único passam JWT entre fornecedores de identidade e fornecedores de serviços. As funções serverless e os workers de borda validam JWT localmente sem consultar uma base de dados, permitindo uma autenticação sem estado e escalável horizontalmente. As apps móveis guardam os JWT como tokens de portador (bearer) e incluem-nos no cabeçalho Authorization de cada pedido de API. Perceber o que está dentro de um token (que permissões concede, quando expira e quem o emitiu) é uma tarefa diária para qualquer engenheiro de backend ou de segurança.

Esta ferramenta descodifica o cabeçalho e a carga útil de qualquer JWT inteiramente dentro do teu navegador. Descodifica em Base64url cada segmento, analisa o JSON e apresenta os claims num formato legível. As marcas temporais numéricas (iat, exp, nbf) são convertidas automaticamente em datas legíveis para que vejas de imediato se um token expirou. A assinatura é mostrada tal como está, mas deliberadamente não é verificada: a verificação requer o segredo do emissor (para HMAC) ou a sua chave pública (para RSA/ECDSA), e nunca deves colar nenhum dos dois numa ferramenta online não fidedigna. Como a descodificação acontece localmente, nem sequer o próprio token sai do teu dispositivo.

Alguns pontos de segurança a ter em conta: os JWT são assinados mas não cifrados por omissão; a carga útil está apenas codificada em Base64url, o que significa que qualquer pessoa que intercete o token pode ler os seus claims. Nunca incluas dados pessoais sensíveis (palavras-passe, números de cartão) na carga útil de um JWT. O ataque alg: none é uma vulnerabilidade conhecida em bibliotecas JWT ingénuas que aceitam tokens não assinados; usa sempre uma biblioteca bem auditada que valide explicitamente o algoritmo. Verifica também o claim exp antes de confiar num token: uma assinatura válida não significa que o token continue ativo.

A ascensão do JSON Web Token

Os JSON Web Token foram introduzidos pela Internet Engineering Task Force (IETF) como parte do grupo de trabalho JOSE (assinatura e cifragem de objetos JSON), com o RFC 7519 publicado em maio de 2015. O objetivo era criar um formato de credencial compacto e autónomo que pudesse substituir as verbosas e complexas asserções SAML em XML usadas nos sistemas empresariais de início de sessão único. O desenho delimitado por pontos e codificado em Base64url foi escolhido deliberadamente para ser seguro em URL e caber confortavelmente dentro de um cabeçalho HTTP.

A adoção foi explosiva. Poucos anos depois da publicação, quase todos os principais frameworks de autenticação, do Auth0 ao Firebase Authentication e ao AWS Cognito, tinham normalizado os JWT como o seu formato de token. O site jwt.io, lançado pela Auth0 como ferramenta de depuração, tornou-se um dos utilitários para programadores mais visitados da internet. Esta popularidade também atraiu escrutínio: os investigadores de segurança catalogaram uma série de vulnerabilidades de implementação (o bug 'alg: none', os ataques de confusão de algoritmos) que afetavam implementações de bibliotecas ingénuas, o que impulsionou uma onda de melhorias nas bibliotecas JWT de todas as linguagens de programação.

Uma decisão de desenho interessante nos JWT é que a carga útil é legível por qualquer pessoa: a assinatura garante a integridade, mas não o sigilo. Isto foi intencional: os criadores queriam que os tokens fossem depuráveis sem uma chave, permitindo que ferramentas como os descodificadores de JWT ajudem os programadores a inspecionar tokens durante o desenvolvimento. A contrapartida é que os programadores têm de ser disciplinados quanto aos claims que incluem, uma lição aprendida da pior forma por equipas que enviaram por acidente JWT com dados sensíveis de utilizadores.

Ferramentas relacionadas

Codificador e Descodificador Base64

Codifica e descodifica texto ou ficheiros em Base64 localmente no teu navegador.

Gerador de Hash (SHA-1, SHA-256, SHA-384, SHA-512)

Calcula hashes criptográficos de texto ou ficheiros localmente: SHA-1, SHA-256, SHA-384 e SHA-512.
Publicidade
Publicidade
Publicidade