Decodificador de JWT
Inspecione o cabeçalho, o payload e a expiração de um JWT.
Sobre esta ferramenta
Decodifique um JSON Web Token para ler o cabeçalho e as claims. Timestamps como exp, iat e nbf aparecem como datas legíveis, e você vê na hora se o token expirou. A assinatura não é verificada.
Como usar
- Cole um JSON Web Token. Um “Bearer ” no início é removido automaticamente.
- Leia o cabeçalho e o payload decodificados.
- Confira o banner de status e as claims de tempo para ver quando o token foi emitido e quando expira.
Perguntas
- Isto verifica a assinatura?
- Não. Ele só decodifica o token. A verificação exige o segredo ou a chave pública e deve acontecer no seu servidor. Nunca confie em um token só porque ele decodifica.
- É seguro colar um token real aqui?
- A decodificação acontece inteiramente no seu navegador e o token nunca é enviado a lugar nenhum. Mesmo assim, trate tokens de produção como senhas e prefira tokens expirados ou de teste quando puder.
- O que significam exp, iat e nbf?
- exp é quando o token expira, iat quando foi emitido e nbf o momento antes do qual ele não deve ser aceito. Os três são timestamps Unix em segundos.
- Qualquer pessoa pode ler o conteúdo de um JWT?
- Sim. O cabeçalho e o payload só estão codificados em Base64url, não criptografados. Não coloque segredos nem dados pessoais sensíveis no payload de um JWT.
- Por que meu token tem cinco partes em vez de três?
- Um token com cinco partes separadas por pontos é um JWE, um JSON Web Token criptografado, definido na RFC 7516. O payload dele não pode ser lido sem a chave de descriptografia, então este decodificador mostra um erro. Um token com só duas partes geralmente foi cortado ao ser copiado; mesmo um token sem assinatura mantém um ponto final.
- O que é o kid no cabeçalho de um JWT?
- kid é o ID da chave. Ele diz ao verificador qual chave usar quando o emissor publica várias, por exemplo em um documento JWKS. Isso torna possível a rotação de chaves: os novos tokens são assinados com uma chave nova, enquanto os tokens assinados com a antiga continuam válidos até expirarem.
- Posso editar o payload de um JWT e continuar usando o token?
- Você pode alterar o payload e codificá-lo de novo, mas a assinatura deixa de bater, então um servidor configurado corretamente rejeita o token. Se um token editado for aceito, o servidor não está verificando assinaturas, o que é uma falha grave de segurança que vale reportar ou corrigir na hora.
O que é um JWT e como ele é estruturado?
Um JSON Web Token, definido na RFC 7519, é uma string compacta de três partes separadas por pontos: cabeçalho, payload e assinatura. O cabeçalho diz como o token é assinado, com um valor alg como HS256 ou RS256. O payload guarda as claims: de quem o token trata (sub), quem o emitiu (iss), a quem se destina (aud) e quando expira (exp). As duas partes são JSON codificado em base64url.
A terceira parte é a assinatura, calculada sobre as duas primeiras com um segredo ou uma chave privada. Como o cabeçalho é um JSON que começa com uma chave e aspas duplas, quase todo JWT começa com eyJ, e é assim que dá para reconhecer um em logs e cabeçalhos de requisição. Cole um token neste decodificador de JWT para ver o cabeçalho e o payload formatados, com as claims de tempo exibidas como datas.
Por que meu JWT é rejeitado mesmo sendo decodificado?
Um token que decodifica sem problemas ainda pode ser recusado, geralmente com um 401. A causa mais comum é a expiração, então confira o aviso de status, que diz se o exp já está no passado. Lembre que o exp é em segundos: um backend que o compara com um tempo em milissegundos do JavaScript vai decidir errado. A diferença de relógio entre servidores também importa, e é por isso que a maioria das bibliotecas permite uma pequena tolerância.
Se os horários parecem certos, compare as claims com o que o servidor espera. Um aud que não corresponde à API, um iss inesperado ou um token de um provedor de identidade de staging enviado para produção falham na validação. A verificação da assinatura falha quando a chave está errada, o token foi editado ou o alg do cabeçalho não é um dos aceitos pelo servidor. Este decodificador não verifica assinaturas, então não consegue dizer qual desses casos se aplica.
HS256 ou RS256: qual algoritmo de JWT usar
O HS256 assina o token com HMAC-SHA256 e um único segredo compartilhado. Todo serviço que verifica tokens precisa desse mesmo segredo, o que também permite que ele crie novos tokens. Isso funciona para um único backend, mas é arriscado com muitos serviços. O RS256 (RSA) e o ES256 (ECDSA) usam um par de chaves: o emissor assina com uma chave privada, e todos os outros verificam com a chave pública, muitas vezes publicada em um endpoint JWKS.
Seja qual for a escolha, fixe o algoritmo permitido no lado que verifica em vez de confiar no campo alg do cabeçalho. Um token com alg definido como none não tem assinatura nenhuma e deve ser sempre rejeitado. Mantenha o exp curto, de minutos e não de dias, e use refresh tokens para sessões mais longas. Você pode ler o alg e o kid no painel do cabeçalho aqui, e conferir qualquer timestamp com o Conversor de timestamp Unix.
Algo não está funcionando ou um resultado parece errado? Relatar um problema com esta ferramenta