Ir para o conteúdo
ToolsMinify logo
Todos os artigos

O que tem dentro de um JWT? Cabecalho, payload e assinatura (2026)

Um JSON Web Token sao tres partes Base64URL unidas por pontos: cabecalho, payload de claims e assinatura. Veja o que cada parte contem, os claims comuns e por que decodificar nao e verificar.

Atualizado em 23 de agosto de 20267 min de leitura

Use o Decodificador JWT - de graça

Abra a ferramenta e aplique o que você aprendeu neste guia.

Abrir Decodificador JWT

Um JSON Web Token (JWT) parece uma string longa e aleatoria, mas sao so tres pedacos de dados colados com pontos. O primeiro diz como o token foi montado. O segundo sao os claims - para quem e, quando expira e o que o emissor colocou. O terceiro e uma assinatura que um servidor confiavel pode checar. Este guia percorre cada parte, os claims do dia a dia e a diferenca entre ler um token e confiar nele. Para inspecionar um token de verdade, cole no Decodificador JWT - roda no navegador e nao faz upload.

Resposta rapida

Um JWT e header.payload.signature. Cabecalho e payload sao JSON em Base64URL. O cabecalho quase sempre tem alg e typ. O payload guarda claims como sub, iat e exp mais campos seus. A assinatura e o terceiro segmento. Decodificar mostra esses JSON. Nao prova que o token e autentico - verificar precisa do segredo ou da chave publica num servidor confiavel.

Tres partes unidas por pontos

A RFC 7519 define um JWT compacto como tres segmentos Base64URL separados por ponto. Nao ha wrapper extra, nao ha JSON por fora e em geral nao ha iguais de padding. Se voce parte em . sempre recebe tres strings, mesmo quando a ultima esta vazia (a forma insegura alg none).

  • Cabecalho: metadados do token, quase sempre JSON com alg e typ.
  • Payload: os claims. E isso que as APIs de fato leem.
  • Assinatura: uma tag criptografica sobre cabecalho e payload. Este artigo e a ferramenta tratam isso como bytes opacos.

Qualquer pessoa que saiba escrever JSON pode inventar um cabecalho e um payload e codificar em Base64URL. Por isso as duas primeiras partes sao publicas. Quem interceptar um JWT le esses claims. Dado confidencial nao cabe num JWT a menos que voce tambem cifre (JWE), que e outro formato.

O cabecalho

O cabecalho diz aos verificadores como tratar o token. E um objeto JSON pequeno. Depois de decodificar o primeiro segmento em Base64URL voce em geral ve:

  • alg - o algoritmo usado para assinar (ou none). Valores comuns: HS256 (HMAC com segredo compartilhado), RS256 ou ES256 (chaves assimetricas).
  • typ - em geral JWT. Alguns emissores omitem.
  • kid - id de chave opcional para o servidor escolher a chave publica certa num JWKS.
  • cty - tipo de conteudo, raro, quando o payload e um JWT aninhado.

O campo perigoso e alg. Um decodificador mostra o que o token afirma. Um verificador ingenuo que aceita alg none, ou que deixa um atacante trocar RS256 por HS256 e assinar com a chave publica como se fosse um segredo HMAC, aceita tokens forjados. Isso e bug de servidor, nao algo que um decodificador no navegador resolva. Leia alg como dica, nunca como prova.

O payload (claims)

O payload e outro objeto JSON. As specs JWT separam claims registrados (um vocabulario pequeno compartilhado) e nomes privados ou publicos que o seu app define. Timestamps sao NumericDate: segundos desde 1970-01-01 UTC, nao milissegundos.

Claims registrados que voce ve o tempo todo

  • iss - emissor. Quem criou o token (uma URL ou o nome do auth server).
  • sub - sujeito. O usuario ou servico de que o token fala.
  • aud - audiencia. A API ou app que deveria aceitar. Pode ser string ou array.
  • exp - expiracao. Recuse o token depois deste tempo Unix.
  • nbf - not before. Recuse o token antes deste tempo Unix.
  • iat - issued at. Quando o emissor criou.
  • jti - id do JWT. Um id unico para revogar ou deduplicar tokens.

Claims customizados

Todo o resto e dado da aplicacao: name, email, role, scope, tenant ou um array de permissoes. E conveniente para APIs e tambem trivial de forjar se voce so decodifica. Um claim role: admin num token colado no decodificador significa que o emissor (ou um atacante) escreveu essa string. Nao e concessao de permissao ate o backend verificar a assinatura e checar iss, aud e exp.

A assinatura

O terceiro segmento nao e JSON. Em HS256 e um HMAC-SHA256 sobre a string ASCII header.payload com um segredo compartilhado. Em RS256 ou ES256 e uma assinatura assimetrica sobre a mesma entrada. O decodificador mostra o texto Base64URL cru para voce comparar tokens; ele nunca recalcula nem valida essa tag. Verificar precisa do segredo ou da chave publica do emissor, e precisa acontecer numa maquina em que voce confia.

Decodificar nao e verificar

Ler o JSON de cabecalho e payload so responde "o que este token afirma?". Um servidor que aceita o token ainda precisa verificar a assinatura, recusar o alg errado, checar exp / nbf / iat e casar iss e aud. O Decodificador JWT e para inspecao e debug, nao para login.

Base64URL, nao Base64 comum

Cabecalho e payload de JWT usam Base64URL (RFC 4648): a mesma codificacao de 6 bits do Base64, mas + vira -, / vira _ e o padding = costuma sumir. Assim o token fica seguro em query strings e headers. Se voce colar um segmento JWT numa ferramenta Base64 generica, restaure os caracteres URL primeiro ou o JSON nao abre. O Codificador / decodificador Base64 e para Base64 comum; a ferramenta JWT ja aplica o alfabeto URL.

Exemplo pratico

O token de demo classico da documentacao JWT decodifica para um cabecalho e um payload minimos. Depois de partir nos pontos e decodificar as duas primeiras partes em Base64URL voce obtem:

  • JSON do cabecalho: {"alg":"HS256","typ":"JWT"}
  • JSON do payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}
  • iat 1516239022 e 2018-01-18 01:30:22 UTC - o token esta anos alem de qualquer exp real se houvesse uma.
  • O terceiro segmento e a assinatura HMAC. Olhar para ela nao diz se o segredo estava certo.

Um prefixo Bearer nao faz parte do JWT. Authorization: Bearer eyJ... e convencao de header HTTP. Remova Bearer e o espaco, depois decodifique os tres segmentos. O decodificador da ToolsMinify faz isso por voce.

O que voce pode ler vs o que o servidor precisa checar

Use um decodificador quando estiver depurando. Use um verificador quando estiver autorizando.

  1. Voce pode ler alg, typ e kid para ver qual chave o emissor pretendia.
  2. Voce pode ler sub, email ou role para entender uma request que falha.
  3. Voce pode comparar exp e iat com o relogio para ver se o token envelheceu.
  4. Um servidor precisa verificar a assinatura com a chave e o algoritmo certos.
  5. Um servidor precisa recusar tokens com iss ou aud errados, e tokens ainda invalidos ou ja expirados.
  6. Um servidor precisa tratar cada claim como nao confiavel ate essas checagens passarem.

Erros comuns

  • Confiar em claims vistos num decodificador. Qualquer um monta header.payload e deixa uma assinatura lixo.
  • Aceitar alg none ou deixar o token escolher o algoritmo de verificacao.
  • Colocar senhas, segredos de sessao ou dados pessoais no payload. O payload e legivel para quem tem o token.
  • Colar tokens de producao num site aleatorio. Prefira um decodificador no cliente para o token nao sair da maquina.
  • Confundir este formato com JWTs cifrados (JWE). Um JWE compacto tem cinco segmentos, nao tres.

Perguntas frequentes

Um JWT e criptografado?

Um JWT assinado padrao (JWS) nao e criptografado. Cabecalho e payload so estao codificados. Quem tem o token le os claims. Tokens cifrados usam JWE e parecem diferentes. Se voce cola um token num decodificador e ve JSON, ele nao era confidencial.

Por que o decodificador nao verifica a assinatura?

Verificar precisa de um segredo ou da chave publica de quem tem a privada. Colocar isso numa pagina publica seria inseguro, e um selo verde de "valido" num site em que voce nao confia ensina a confiar na checagem errada. Decodifique localmente; verifique na sua API.

O que significa alg none?

Significa que o emissor (ou um atacante) marcou o token como nao seguro. O terceiro segmento esta vazio. Um decodificador ainda mostra cabecalho e payload. Uma API de producao deveria recusar alg none, salvo um motivo local e explicito para aceitar tokens sem assinatura.

exp e iat sao em milissegundos?

Nao. NumericDate de JWT sao segundos desde o epoch Unix. Se um claim parece 1.7e12 voce provavelmente esta vendo Date.now() do JavaScript em milissegundos por engano.

Posso remontar um token depois de editar o payload?

Voce pode recodificar o JSON para Base64URL e juntar tres segmentos, mas a assinatura antiga nao vai mais bater. Sem o segredo ou a chave privada do emissor o token novo e forjado. Isso e esperado. Decodificadores servem para ler, nao para emitir tokens de producao.

Onde inspecionar um token com seguranca?

Use uma pagina que decodifica no navegador e nao faz upload da string. O Decodificador JWT da ToolsMinify faz isso. Para o passo a passo, veja Como usar o Decodificador JWT.

Inspecione um token no navegador

Cole um JWT para ver cabecalho, payload e assinatura em secoes legiveis. Nada e enviado:

Decodifique um JWT - gratis

Abra o Decodificador JWT, cole um token e leia o cabecalho e os claims. A assinatura aparece como esta e nunca e verificada. Tudo roda no navegador.

Use o Decodificador JWT - de graça

Abra a ferramenta e aplique o que você aprendeu neste guia.

Abrir Decodificador JWT

Artigos relacionados